From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Monday, September 23, 1996 8:38 AM
To:	1394ohci-l
Subject:	-No Subject-

Greetings,

   The reflector is open.  Please note that
the name is 1394ohci-l (not 1394ohci as 
originally proposed).

   Happy reflecting.  I am setting up the 
ftp site for the presentations, etc.   They'll
be out soon.
From:	Yih-Sheng Wey [yswey@sis.com.tw]
Sent:	Tuesday, September 24, 1996 1:23 PM
To:	1394ohci-l; Lee Wilson
Subject:	Re: -No Subject-

Dear Mr. Wilson,

I am Yih-Sheng Wey, the design director of Silicon Integrated System Corp.
We are a member of 1394 TA and I would appreciate if you can put me into
the reflector. Please let me know if there is any procedures that I need
to follow. Thanks,

My email address: yswey@sis.com.tw


> Greetings,
> 
>    The reflector is open.  Please note that
> the name is 1394ohci-l (not 1394ohci as 
> originally proposed).
> 
>    Happy reflecting.  I am setting up the 
> ftp site for the presentations, etc.   They'll
> be out soon.
> 
> 
> 
From:	daisy@sis.com.tw
Sent:	Tuesday, September 24, 1996 6:27 PM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Subject:	1394_OHCIv06_Question_Log1

Hi, 

I have some questions about OHCIv06 spec.
    
1. ack_data_error and ack_type_error for asynchronous transmission,
   When Link receive a packet and find that it has data CRC error, then Link
   will return ack_data_error,
   (a). should Link discard this packet ? 
   (b). If not, what will driver do with this packet? And, how about if this 
        is a request packet, will driver return a response packet ?
   (c). what shall Link do if it found the packet was a type_error one? Should
        it discard the packet ?

2. OHCI 1.4.12 mentions that Link should receive Isoch packet at all times,
   and explains that Link may receive a cycle start packet with CRC error,
   causes OHCI can't switch to Isoch cycle successfully. 
   (a). Since we should receive Isoch packet at all times, how to guarantee the
        Asyn. bandwith?
   (b). Can we transmit Isoch packet in Async period ?
   (c). The bit "isoActive" in Node ID register should be redefined when we
        should receive Isoch packets at all times.

3.  the sentence : the root PHY will have phy_ID of zero.... in OHCIv05
    why it is canceled in OHCIv06 ?

4.  When transmitting Asyn packet, OHCI will decide the data length in terns of
    the buffers specified by driver (DBDMA commands), why in table 7-3 block
    data field says, if the dataLength == 0, no data should be written into the
    FIFO ? Should we check the dataLength field of the header ?

5. Same question as 6. In table 7-4 Asyn. receive, should we discard all data
   field if the dataLength is zero ?

6. Since the async transmit DMA only supports the single phase retry protocol
   (OCHI, p3), Is the bit "busyState" in Node ID register necessary ?

Thanks for your help,




====================================
Yen-Jiuan Chao (Daisy)
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	Yehuda Peled [ypeled@VNET.IBM.COM]
Sent:	Wednesday, September 25, 1996 7:26 AM
To:	1394ohci-l@austin.ibm.com
Cc:	ADAR@HAIFASC3.VNET.IBM.COM; ypeled@VNET.IBM.COM
Subject:	Reallocation of isochronous resources after a 1394 bus reset.

Following a note from one of our designers raising a problem with the
reallocation of isoc resources after a 1394 bus reset.
Any respond will be appreciate.

Thanks
 Yehuda
-----------------------------------------------------------------------
Date: 25 September 1996, 14:16:26 IST
From: ADAR at HAIFA
To:   PELED at HAIFASC3


Yehuda could you forward this question to the HCI ?

I have a question which I would like you to clarify regarding
isochronous resource reallocation.

After a bus reset all nodes on the bus must reallocate bandwidth
from the isoc master. The way I understand this works is that
each node reads the "bandwidth" register and then sends a lock request.
All nodes do this after reset so we will see N reads then an
arbitration reset gap and N lock packets being sent to the isoc
manager. Only one of them will succeed (the first one).
Then N-1 members of the bus (whom failed) send a read request to
that register and again after an arbitration reset gap N-1 lock requests.
In this way (if I understand it correctly) we will have (N factorial)*2
packets until all are satisfied and 2*N arbitration reset gaps.
Is this how it works ?
Where did I go wrong ?

Thanks
 Etai
From:	scotts@lsi.sel.sony.com
Sent:	Wednesday, September 25, 1996 8:17 AM
To:	Yehuda Peled; 1394ohci-l@austin.ibm.com
Cc:	ADAR@HAIFASC3.VNET.IBM.COM; ypeled@vnet.ibm.com
Subject:	Re: Reallocation of isochronous resources after a 1394 bus reset.

Well, it's not so bad as all this.

First of all, only the nodes which own isochronous resources need to
reallocate them after a bus reset.  This could be 63 nodes, but in practice
it is only one or two.

In the most straight forward example, following the bus reset, all nodes
which previously owned isochronous resources read the bandwidth available
register, then perform a compare_swap.  The nodes which fail do not need to
do another read because the response packet of the compare_swap contains
the old value, so these nodes can perform another compare_swap immediately.

So, in one scenario, N nodes perform a read in one fairness interval, then
perform a compare_swap in the next fairness interval.  In the next fairness
interval, N-1 nodes perform the compare_swap operation again, then N-2,
etc.  It's not a multiplicative function, it's additive, so we don't get a
factorial, we get N + (N-1) + (N-2), etc.  If there are 5 such nodes which
owned isochronous resources, the number of fairness intervals is 5, and the
number of transactions is 5 + 4 + 3 + 2 + 1 = 15, not 5 factorial (did I
get your meaning right?)

As another efficiency operation, notice that if all nodes assumed that the
bandwidth available register contains the initial value, then the initial
read transaction by all nodes is not necessary!  I incorporated this
assumption into my number above.

Scott

At 6:25 AM 9/25/96, Yehuda Peled wrote:
>Following a note from one of our designers raising a problem with the
>reallocation of isoc resources after a 1394 bus reset.
>Any respond will be appreciate.
>
>Thanks
> Yehuda
>-----------------------------------------------------------------------
>Date: 25 September 1996, 14:16:26 IST
>From: ADAR at HAIFA
>To:   PELED at HAIFASC3
>
>
>Yehuda could you forward this question to the HCI ?
>
>I have a question which I would like you to clarify regarding
>isochronous resource reallocation.
>
>After a bus reset all nodes on the bus must reallocate bandwidth
>from the isoc master. The way I understand this works is that
>each node reads the "bandwidth" register and then sends a lock request.
>All nodes do this after reset so we will see N reads then an
>arbitration reset gap and N lock packets being sent to the isoc
>manager. Only one of them will succeed (the first one).
>Then N-1 members of the bus (whom failed) send a read request to
>that register and again after an arbitration reset gap N-1 lock requests.
>In this way (if I understand it correctly) we will have (N factorial)*2
>packets until all are satisfied and 2*N arbitration reset gaps.
>Is this how it works ?
>Where did I go wrong ?
>
>Thanks
> Etai

=========================================================================
| Scott Smyers                  | Tel: (408) 955-4573                   |
| Sony Research Laboratories    | Cel: (408) 930-7950                   |
| LSI Systems Laboratory        | Fax: (408) 955-5180                   |
| 3300 Zanker Road, M/S SJ3D3   | email:  scotts@lsi.sel.sony.com       |
| San Jose, CA 95134            | AOL: smyers@aol.com (when travelling) |
=========================================================================


From:	Michael D. Johas Teener - CTO Firefly, Inc. [mike@fireflyinc.com]
Sent:	Wednesday, September 25, 1996 3:09 PM
To:	Yehuda Peled
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: Reallocation of isochronous resources after a 1394 bus reset.

>After a bus reset all nodes on the bus must reallocate bandwidth
>from the isoc master. The way I understand this works is that
>each node reads the "bandwidth" register and then sends a lock request.
>All nodes do this after reset so we will see N reads then an
>arbitration reset gap and N lock packets being sent to the isoc
>manager. Only one of them will succeed (the first one).
>Then N-1 members of the bus (whom failed) send a read request to
>that register and again after an arbitration reset gap N-1 lock requests.
>In this way (if I understand it correctly) we will have (N factorial)*2
>packets until all are satisfied and 2*N arbitration reset gaps.
>Is this how it works ?
>Where did I go wrong ?
>

It's not quite that bad. 

1) You don't do a read followed by a compare-swap. You just do
compare-swap. If it fails, you have the correct value returned in a new
compare-swap.

2) I doubt if everyone is fast enough to do a full request each fairness
interval since most apps will use firmware ....

3) ... and that is the *real* reason we allow so much time (a significant
fraction of a second) for all this to settle down.
===================================================================
Michael D. Johas Teener
Chief Technical Officer, Firefly, Inc.
269 Mt. Herman Rd. #102, Scotts Valley, CA 95066-4000
phone: +1-408-461-4901           fax: +1-408-461-1394
email: mike@fireflyinc.com
===================================================================


From:	Mourn, Richard [RMOURN@COSSYMWEST.CO.SYMBIOS.COM]
Sent:	Friday, September 27, 1996 8:35 AM
To:	1394ohci-l; leew; Yehuda Peled
Cc:	ADAR
Subject:	Re: Reallocation of isochronous resources after a 1394 bus reset.


I still believe that this is worst case. It seems that different nodes would take different amounts of time to start this process. Things like cameras and other devices running from firmware first and computers running from host based software later.

Also, if a node (maybe a computer) allocates the resources for several devices (hdd, teleconferencing camera, scanner etc.) it could do so in one compare and swap.

Regards, Richard
 ----------
From: leew
To: Yehuda Peled; 1394ohci-l
Cc: ADAR; ypeled
Subject: Re: Reallocation of isochronous resources after a 1394 bus reset.
Date: Wednesday, September 25, 1996 7:17AM

Well, it's not so bad as all this.

First of all, only the nodes which own isochronous resources need to
reallocate them after a bus reset.  This could be 63 nodes, but in practice
it is only one or two.

In the most straight forward example, following the bus reset, all nodes
which previously owned isochronous resources read the bandwidth available
register, then perform a compare_swap.  The nodes which fail do not need to
do another read because the response packet of the compare_swap contains
the old value, so these nodes can perform another compare_swap immediately.

So, in one scenario, N nodes perform a read in one fairness interval, then
perform a compare_swap in the next fairness interval.  In the next fairness
interval, N-1 nodes perform the compare_swap operation again, then N-2,
etc.  It's not a multiplicative function, it's additive, so we don't get a
factorial, we get N + (N-1) + (N-2), etc.  If there are 5 such nodes which
owned isochronous resources, the number of fairness intervals is 5, and the
number of transactions is 5 + 4 + 3 + 2 + 1 = 15, not 5 factorial (did I
get your meaning right?)

As another efficiency operation, notice that if all nodes assumed that the
bandwidth available register contains the initial value, then the initial
read transaction by all nodes is not necessary!  I incorporated this
assumption into my number above.

Scott

At 6:25 AM 9/25/96, Yehuda Peled wrote:
>Following a note from one of our designers raising a problem with the
>reallocation of isoc resources after a 1394 bus reset.
>Any respond will be appreciate.
>
>Thanks
> Yehuda
>-----------------------------------------------------------------------
>Date: 25 September 1996, 14:16:26 IST
>From: ADAR at HAIFA
>To:   PELED at HAIFASC3
>
>
>Yehuda could you forward this question to the HCI ?
>
>I have a question which I would like you to clarify regarding
>isochronous resource reallocation.
>
>After a bus reset all nodes on the bus must reallocate bandwidth
>from the isoc master. The way I understand this works is that
>each node reads the "bandwidth" register and then sends a lock request.
>All nodes do this after reset so we will see N reads then an
>arbitration reset gap and N lock packets being sent to the isoc
>manager. Only one of them will succeed (the first one).
>Then N-1 members of the bus (whom failed) send a read request to
>that register and again after an arbitration reset gap N-1 lock requests.
>In this way (if I understand it correctly) we will have (N factorial)*2
>packets until all are satisfied and 2*N arbitration reset gaps.
>Is this how it works ?
>Where did I go wrong ?
>
>Thanks
> Etai

=========================================================================
| Scott Smyers                  | Tel: (408) 955-4573                   |
| Sony Research Laboratories    | Cel: (408) 930-7950                   |
| LSI Systems Laboratory        | Fax: (408) 955-5180                   |
| 3300 Zanker Road, M/S SJ3D3   | email:  scotts@lsi.sel.sony.com       |
| San Jose, CA 95134            | AOL: smyers@aol.com (when travelling) |
=========================================================================


From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Friday, September 27, 1996 3:41 AM
To:	1394ohci-l
Subject:	PDFs on FTP Site

Greetings,

   PDFs for all the conference presentations
and a PDF for the OpenHCI version .6 specification
are now available at: 

ftp://www.austin.ibm.com/pub/chrptech/1394ohci/

  Note that this is a ftp site - not an HTTP site.

  Best Regards,
  Lee Wilson
From:	DavidW@bangate.compaq.com
Sent:	Friday, September 27, 1996 1:29 PM
To:	ypeled@vnet.ibm.com
Cc:	hciboys-l@austin.ibm.com; ADAR@HAIFASC3.VNET.IBM.COM
Subject:	re: Reallocation of isochronous resources after a 1394 bus rese

Yehuda,

Please let Etai know that he has it exactly correct.  This is one reason why 
we moved the isochronous resource registers into hardware.  Seemed like SW 
might have a bit of a problem handling all these requests in the allotted time 
(time limit is a second I think.) 

We also hope that N is not particularly large.

David


"Yehuda Peled" <ypeled@VNET.IBM.COM> Wrote:
| 
| Following a note from one of our designers raising a problem with the
| reallocation of isoc resources after a 1394 bus reset.
| Any respond will be appreciate.
| 
| Thanks
|  Yehuda
| -----------------------------------------------------------------------
| Date: 25 September 1996, 14:16:26 IST
| From: ADAR at HAIFA
| To:   PELED at HAIFASC3
| 
| 
| Yehuda could you forward this question to the HCI ?
| 
| I have a question which I would like you to clarify regarding
| isochronous resource reallocation.
| 
| After a bus reset all nodes on the bus must reallocate bandwidth
| from the isoc master. The way I understand this works is that
| each node reads the "bandwidth" register and then sends a lock request.
| All nodes do this after reset so we will see N reads then an
| arbitration reset gap and N lock packets being sent to the isoc
| manager. Only one of them will succeed (the first one).
| Then N-1 members of the bus (whom failed) send a read request to
| that register and again after an arbitration reset gap N-1 lock requests.
| In this way (if I understand it correctly) we will have (N factorial)*2
| packets until all are satisfied and 2*N arbitration reset gaps.
| Is this how it works ?
| Where did I go wrong ?
| 
| Thanks
|  Etai
| 
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Friday, September 27, 1996 10:27 AM
To:	1394ohci-l
Subject:	Re: PDFs on FTP Site

Greetings,
   
    The PDF for the OpenHCI Version .6 document had
a bug and could not be retrieved successfully from the
FTP site.  This bug is now fixed.  Please find a good PDF
available there at this time.  The file is NOT uuencoded, 
etc. :=)

  Best Regards,
  Lee Wilson

To: leew @ austin.ibm.com (Lee Wilson) @ AUSSMTP
cc:  (bcc: Lee Wilson)
From: f_campbell @ qlc.com (Frank Campbell) @ AUSSMTP
Date: 09/27/96 02:07:20 PM
Subject: Re: PDFs on FTP Site
Security: 
 
Lee Wilson wrote:
> 
> Greetings,
> 
>    PDFs for all the conference presentations
> and a PDF for the OpenHCI version .6 specification
> are now available at:
> 
> ftp://www.austin.ibm.com/pub/chrptech/1394ohci/
> 
>   Note that this is a ftp site - not an HTTP site.
> 
>   Best Regards,
>   Lee Wilson

Thank you for putting these files up.

I am having trouble with one of them, the OpenHCI version
.6 spec. It appears to be UUENCODED, but the decode results
in a file that Acrobat Reader rejects as damaged and unrepairable.

All the other files are fine.

Has anybody else had this problem, or do to need to do 
something about my uudecoder or acrobat version.

Thanks


Frank Campbell
Qlogic


  

From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Monday, September 30, 1996 3:52 AM
To:	1394ohci-l
Subject:	Re[2]: PDFs on FTP Site

Greetings,

   I was able to open ohcidma2.pdf off of the
ftp site using Microsoft Internet Explorer and
Acrobat Exchange.  

   Is anyone else having a problem (see attached)?
Patrick - try downloading it again.  I cannot recreate
your problem :=).

   Best Regards,
   Lee Wilson 

To: leew @ austin.ibm.com (Lee Wilson) @ AUSSMTP
cc:  (bcc: Lee Wilson)
From: Patrick_Yu @ el.nec.com @ AUSSMTP
Date: 09/27/96 07:16:41 PM
Subject: Re[2]: PDFs on FTP Site
Security: 
 
les,

I have similar problem with the file "ohcidma2.pdf".  Could you also check this 
up please?  Thank you.

Yours sincerely,
W.S.P. Yu

______________________________ Reply Separator _________________________________
Subject: Re: PDFs on FTP Site
Author:  Lee Wilson <leew@austin.ibm.com> at INTERNET
Date:    9/27/96 5:26 PM


Greetings,
     
    The PDF for the OpenHCI Version .6 document had
a bug and could not be retrieved successfully from the 
FTP site.  This bug is now fixed.  Please find a good PDF 
available there at this time.  The file is NOT uuencoded, 
etc. :=)
     
  Best Regards,
  Lee Wilson
     
To: leew @ austin.ibm.com (Lee Wilson) @ AUSSMTP 
cc:  (bcc: Lee Wilson)
From: f_campbell @ qlc.com (Frank Campbell) @ AUSSMTP 
Date: 09/27/96 02:07:20 PM
Subject: Re: PDFs on FTP Site
Security: 
     
Lee Wilson wrote:
> 
> Greetings,
> 
>    PDFs for all the conference presentations
> and a PDF for the OpenHCI version .6 specification 
> are now available at:
> 
> ftp://www.austin.ibm.com/pub/chrptech/1394ohci/ 
> 
>   Note that this is a ftp site - not an HTTP site. 
> 
>   Best Regards,
>   Lee Wilson
     
Thank you for putting these files up.
     
I am having trouble with one of them, the OpenHCI version 
.6 spec. It appears to be UUENCODED, but the decode results
in a file that Acrobat Reader rejects as damaged and unrepairable.
     
All the other files are fine.
     
Has anybody else had this problem, or do to need to do 
something about my uudecoder or acrobat version.
     
Thanks
     
     
Frank Campbell
Qlogic
     
     
     
     


  

From:	Patrick_Yu@el.nec.com
Sent:	Monday, September 30, 1996 10:36 AM
To:	1394ohci-l@austin.ibm.com; Lee Wilson
Subject:	Re[3]: PDFs on FTP Site

Lee, 

Thank you for taking time to do the experiment.  I'll try it again.  Thank you.

Yours sincerely,
W.S.P. Yu

______________________________ Reply Separator _________________________________
Subject: Re[2]: PDFs on FTP Site
Author:  Lee Wilson <leew@austin.ibm.com> at INTERNET
Date:    9/30/96 10:51 AM


Greetings,
     
   I was able to open ohcidma2.pdf off of the
ftp site using Microsoft Internet Explorer and 
Acrobat Exchange.  
     
   Is anyone else having a problem (see attached)?
Patrick - try downloading it again.  I cannot recreate 
your problem :=).
     
   Best Regards,
   Lee Wilson 
     
To: leew @ austin.ibm.com (Lee Wilson) @ AUSSMTP 
cc:  (bcc: Lee Wilson)
From: Patrick_Yu @ el.nec.com @ AUSSMTP 
Date: 09/27/96 07:16:41 PM
Subject: Re[2]: PDFs on FTP Site
Security: 
     
les,
     
I have similar problem with the file "ohcidma2.pdf".  Could you also check this 
up please?  Thank you.
     
Yours sincerely,
W.S.P. Yu
     
______________________________ Reply Separator _________________________________
Subject: Re: PDFs on FTP Site
Author:  Lee Wilson <leew@austin.ibm.com> at INTERNET 
Date:    9/27/96 5:26 PM
     
     
Greetings,
     
    The PDF for the OpenHCI Version .6 document had
a bug and could not be retrieved successfully from the 
FTP site.  This bug is now fixed.  Please find a good PDF 
available there at this time.  The file is NOT uuencoded, 
etc. :=)
     
  Best Regards,
  Lee Wilson
     
To: leew @ austin.ibm.com (Lee Wilson) @ AUSSMTP 
cc:  (bcc: Lee Wilson)
From: f_campbell @ qlc.com (Frank Campbell) @ AUSSMTP 
Date: 09/27/96 02:07:20 PM
Subject: Re: PDFs on FTP Site
Security: 
     
Lee Wilson wrote:
> 
> Greetings,
> 
>    PDFs for all the conference presentations
> and a PDF for the OpenHCI version .6 specification 
> are now available at:
> 
> ftp://www.austin.ibm.com/pub/chrptech/1394ohci/ 
> 
>   Note that this is a ftp site - not an HTTP site. 
> 
>   Best Regards,
>   Lee Wilson
     
Thank you for putting these files up.
     
I am having trouble with one of them, the OpenHCI version 
.6 spec. It appears to be UUENCODED, but the decode results
in a file that Acrobat Reader rejects as damaged and unrepairable.
     
All the other files are fine.
     
Has anybody else had this problem, or do to need to do 
something about my uudecoder or acrobat version.
     
Thanks
     
     
Frank Campbell
Qlogic
     
     
     
     
     
     
     
     

From:	Kazuyuki_Abe@SJ-PCEG.ccgw.nec.com
Sent:	Monday, September 30, 1996 1:34 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Please change my E-Mail Address

     Dear administrator for 1394ohci-l reflector,
     
     Please change my E-Mail address.
     
      KazAbe@aol.com => kabe@SJ-PCEG.ccgw.nec.com
     
     With Best Regards,
     Kaz
     
     ======================================================== 
     Kaz (Kazuyuki) Abe 
     
     PC Engineering Group           (415)528-5904 Direct 
     NEC Systems Laboratory, Inc.   (415)528-5900 Fax. 
     339 North Bernardo Ave.,       kabe@SJ-PCEG.ccgw.nec.com 
     Mountain View, CA 94043 
     ========================================================
From:	Dan Bezzant [bezzant@cirrus.com]
Sent:	Monday, September 30, 1996 4:29 PM
To:	1394ohci-l@austin.ibm.com
Subject:	OpenHCI 0.6 Table 2-3 Register Address Map

Draft 0.6 appears to have a double definition of offset 10'h008:
both as Node ID and GUID_ROM registers.

-- 

Dan Bezzant
Cirrus Logic, Inc.

email:	bezzant@cirrus.com
voice:	+1-510-623-8300 Ext. 5709
fax:	+1-510-252-6080
mail:	Dan Bezzant M/S 537B8
	Cirrus Logic, Inc.
	3100 W. Warren Ave.
	Fremont, CA 94538-6423
	USA
From:	daisy@sis.com.tw
Sent:	Tuesday, October 01, 1996 2:16 AM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Subject:	1394_OHCIv06_Question_Log2 : question about enableAT

Hi,

I have a question about enableAT in OHCI. Table 7-1 said, After a bus reset, 
all asynchronous transmit packets are flushed until a packet header with this 
bit is presented. Under this case, should DBDMA update any status of these 
DBDMA commands ?

Thanks.
====================================
Yen-Jiuan Chao (Daisy)
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	klashman@meow.East.Sun.COM
Sent:	Tuesday, October 01, 1996 9:58 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: OpenHCI 0.6 Table 2-3 Register Address Map

>From: Dan Bezzant <bezzant@cirrus.com>
>
>Draft 0.6 appears to have a double definition of offset 10'h008:
>both as Node ID and GUID_ROM registers.
>

Dan,

Thank you for pointing this out.
This will be fixed in the next revision.

Diana

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From:	N_Furuya [furuya@sl3ew80.lsi.tmg.nec.co.jp]
Sent:	Wednesday, October 02, 1996 5:54 AM
To:	1394ohci-l@austin.ibm.com
Cc:	furuya@sl3ew80.lsi.tmg.nec.co.jp
Subject:	Some mistakes in OpenHCI rev0.6


I think there are some simple mistakes in OpenHCI rev0.6.

1) Page 5. There is a following sentense:
   Link supports "for both the single and dual phase retry protocol for
   received packets."
   --> Register field, according to this field Link selects inbound single
   or dual phase retry protocol, is missing.(in Control register?) 

2) Page 6. In Table 1-1, Condition of "ack_complete" and "ack_pending":
   "the top 1GB" -> "the top 4GB"
   or mentioned address region is not correct? 

3) Page 14. In Fugure 3-2:
   "strictIsoch" field is not necessary.
   (In page 5, "Link receives isoch packets at all time.". And
    the description of strictIsoch field has already been eliminated from
    table 3-3.) 

4) Page 15. In Table 3-3, description of "respTxEnable":
   There are following sentences,
   "The RSTF and response transmitter are reset when this bit tranistions
    from a zero to a one. The RSTF is reset when this bit transitions form
    a zero to to a one." 
    --> The second sentence would not be necessary, or "RSTF" would be other
    unit name.   

5) Page 27. In Table 4-1. 
   "DRQTU" -> "DRQU"
   "DRSTU" -> "DRSU"

6) Page 33. In Table 5-3.
   Read value of InterruptSelect : "InterruptSelect"
   Read value of WaitSelect : "ByteCount" --> "WaitSelect"

7) Page 43. In Table 6-3, meaning of s5 bit:

   "s4 is asserted. s4 is cleared." : s4 -> s5 

   The following sentences does not match ATRetries register.
   RetryCount field has already been eliminated from ATRetries register.

   "Not that the internal retry count is one of the fields of the ATRetries
    register, and is accessible to software."  

8) Page 44. 
   The following sentences dose not match Interrupt register.
   PSOutOfRetries field has already been eliminated from Interrupt register.

   "and will assert PSOutOfRetries, which is accessible through the
    ..................................
    fields of the ATRetries register, and accessible to software."

 
 Nobuo Furuya

#    NEC Corporation                                      #
#    3rd Circuit Engineering Department                   #
#    C&C LSI Development Division                         #
#                                                         #
#    Nobuo Furuya                                         #  
#    E-MAIL ADDRESS:  n-furuya@lsi.tmg.nec.co.jp          #
#    TEL: +81-44-435-1616, FAX: +81-44-435-1911           #
From:	Mourn, Richard [RMOURN@COSSYMWEST.CO.SYMBIOS.COM]
Sent:	Wednesday, October 02, 1996 12:26 PM
To:	1394ohci-l
Subject:	How to handle data_error


I have a question on how to handle data  errors. If a node sends a block packet and it receives an acknowledge of data_error how should it react.

1) stop and allow firmware/software to figure out what is wrong (this is how openHCI would handle it)
2) retry the packet automatically just like a busied packet. (in this case should we use the maxRetries value used for Busied packets,  we may need to define an interrupt  for this condition. Do we need to follow fairness for the remainder of the retries?

Do we need to define a consistant way of handling this case on the receive end. Example: if physical block write request is attempted, the responder receives the request, checks the header (it's good) and starts placing the data into the fifo and then into memory/to the media. At the end of the transfer the data is found to be corrupt (data CRC error), ack of data error is sent. Depending on our answer 1) or 2) the retry of the packet could happed within useconds or mseconds. Does the device act as if nothing happened and the retried packet will come in later, or does it indicate the error in some way? For HDD (and other embedded implementations) is trailing status enough or does this need to be a signal generated by the receiver which bypasses the fifo?

Also, in the openHCI spec is there a way to report that the PSU exceeded its retry limit??

Regards, Richard Mourn
Symbios Logic
719-533-7421
richard.mourn@symbios.com
From:	N_Furuya [furuya@sl3ew80.lsi.tmg.nec.co.jp]
Sent:	Thursday, October 03, 1996 1:26 AM
To:	1394ohci-l@austin.ibm.com
Cc:	furuya@sl3ew80.lsi.tmg.nec.co.jp
Subject:	Question about OHCI rev0.6


 I have questions on outbound retry in OpenHCI rev0.6.

 1) I think ATDMA status bit "s5" (page 43,table 6-3) should be cleared
    when "good" acknowledge is received. This allows ATDMA exits looped
    commands(such as clause 6.2.2 example) before retry limit is expired.
    Is this consideration correct?

 2) If 1) is true: 
    In clause 6.2.2 example, I think, "i" field in the command, that
    "output_last" is executed, is normally programmed to c=1(Interrupt on
    good ack).    Is this consideration correct?


 3) I think, ATDMA does not normally generate interrupt when error such
    as "ack_data_error" occurs before retry limit is expired(according to
    the command program), and software usually checks the latest status on
    Command.xferStatus field.  Is this true?

 4) Page 32, condition bit "c" is defined as a bit "which is tested at the
    completion of each command", for interrupt, branch and Waitselect.  

    In some commands for ATDMA, I think, condition bits should be tested
    at reception of acknowledge or subaction gap event.
    I think, when "cmd" field equals to "output_last" or "NOP", ATDMA
    has to wait appropriate event to test condition bit. In this case,
    write to Command.xferStatus and resCount is proceeded after this
    condition check. Is this true?


 5) I think, "Physical Response Unit" does not indicate any information,
    such as received acknowledge code, retry status or success/failure of
    response, to firmware/software.  Is this true?



 6) Page 3, there is a sentence "asynchronous transmit DMA only supports
    the single phase retry protocol(retry-X)."  
    Why ATDMA does not support dual-phase outbound retry protocol ?
    I think dual-phase outbound retry logic is simpler than dual-phase
    inbound.


 Best Regards,
 Nobuo Furuya

 NEC Corporation
 Nobuo Furuya  
 E-MAIL ADDRESS:  n-furuya@lsi.tmg.nec.co.jp
 TEL: +81-44-435-1616, FAX: +81-44-435-1911
From:	PJohansson@aol.com
Sent:	Thursday, October 03, 1996 11:49 AM
To:	1394-architecture@apple.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	Application Retries of DATA_ERROR

This error, unlike the various BUSY_? conditions that the LINK can handle
automatically, must be kicked back to the application for its handling.

The principal reason is that the application is the only entity that knows
enough about the characteristics of the Serial Bus address in the write
request.

If the address (or address range) treats writes as idempotent operations,
e.g., the typical memory model with no interrupts associated, the application
is free to retry after a DATA_ERROR. The assumption here, naturally, is that
the node that received the write with the data error generated no
TR_DATA.indication internally---after all, the data CRC was bad so "nothing"
was received.

On the other hand, if the Serial Bus address referenced by the write request
has side effects, e.g. a location that generates an interrupt when
referenced, the application may not be able to retry the write and may have
to rely on higher level error recovery.

In any case, it is only the application that knows how to handle the retry.

As far as target behavior goes upon receipt of a write or lock request with a
bad data CRC, I recommend that (to the extent permitted by the
implementation) that the request be treated as if it had not been received.
In some applications, e.g., the "tailgate" under discussion in the Disk Boys
group, this may not be possible.

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	Hisato Shima [shima@ssl.sel.sony.com]
Sent:	Thursday, October 03, 1996 12:55 PM
To:	PJohansson@aol.com; 1394-architecture@apple.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: Application Retries of DATA_ERROR

Peter,

> This error, unlike the various BUSY_? conditions that the LINK can handle
> automatically, must be kicked back to the application for its handling.

I agree your comment as a concept, as well as an implementation
guideline, but I have concern about how the 1394 formal service model
treat this error.  I think this problem in service model generates 
confusion about error handling. 

The 1394 architecture defines the layers of protocol and communication
between them as shown in Figure 3-4.  The application is not shown
in the figure but assumed to be outside of upper edge of the figure,
and all the open arrows are directed to/from application, operating
system or something outside of the scope of 1394.

When a CRC error occurs and ack_data_error is received for a response 
packet, the standard specifies that transaction layer generates
TR_EVENT.indication which sent to serial bus management according
to the figure 3-4 and not to the application.
Also, from the application point of view, it may be difficult to retry 
the transmission of response because the transaction is considered 
finished when it send a TA_DATA.response.

I don't think there is a problem in actual implementation in adding
a message from transaction layer to application indicating the result
of response packet transmission, but I am still somewhat uncomfortable
because it does not exactly match the model defined in the standard.

==================
Hisato Shima
Sony Research Laboratories
3300 Zanker Road, MD:SJ3D1, San Jose, CA 95134-1940
Tel : (408)955-5524    Fax (408)955-5704
Email  shima@ssl.sel.sony.com

From:	Michael D. Johas Teener - CTO Firefly, Inc. [mike@fireflyinc.com]
Sent:	Thursday, October 03, 1996 2:35 PM
To:	Mourn, Richard; 1394ohci-l
Subject:	Re: How to handle data_error

In general ...

>1) stop and allow firmware/software to figure out what is wrong (this is
how 
>openHCI would handle it)

This *is* correct.

>2) retry the packet automatically just like a busied packet. (in this case

>should we use the maxRetries value used for Busied packets,  we may need
to 
>define an interrupt  for this condition. Do we need to follow fairness for

>the remainder of the retries?

Please, no automatic retry of transactions unless you *really* know what
you are doing.

a) If it is write request, the responder does nothing other than report the
error. There may be corrupted data stored, but that's life in a pipelined
system. The driver needs to be notified in case this write has side
effects.

b) If it is a read response, the responder (sender of the packet) does
nothing other than (perhaps) log the error. The requester (receiver of the
packet) will typically retry the *entire* request. Depending on the
application, there may be side effects ... that's why the driver should be
notified, and perhaps even the higher level (SBP for instance) request
retried.

===================================================================
Michael D. Johas Teener
Chief Technical Officer, Firefly, Inc.
269 Mt. Herman Rd. #102, Scotts Valley, CA 95066-4000
phone: +1-408-461-4901           fax: +1-408-461-1394
email: mike@fireflyinc.com
===================================================================


From:	cylin@sis.com.tw
Sent:	Friday, October 04, 1996 3:06 AM
To:	1394ohci-l@austin.ibm.com
Subject:	PHY control/Node ID register

Hi, all:

Here is my questions concerning the PHY control and Node ID 
registers, and relevant bits in the IntEvent register in OHCI0.6:

1) In 3.6, it said that "rdAddr field should be compared to the value
expected because the PHY can automatically send a register, such as 
   the nodeID register, and thus replace the contents of the read
   before software can look at it". Who should do the comparison?-
   software or hardware? If done by software, then how to guarantee
   that software gets the desired data? If done by hardware, then
   the rdAddr field is redundant because rdAddr always equals to
   regAddr.

2) Also in 3.6, it said that "PHY can autonomously send the contents 
   of register 0 to the link. This data is routed automatically to the
   NodeID register and does not effect the PHY control register". When
   this occurs, how does hardware inform software? Should it set
   the phyInt bit of the IntEvent register?

3) What event(s) should cause phyInt?

4) Should the automatically sent PHY register contents cause the
   phyRegRcvd to be set? If the comparison in 1) is done by software,
   then this bit should be set according to the definition of
   phyRegRcvd in OHCI0.5: "The 1394 Open HCI has received a PHY register
   data byte which can be read from the PHY control register". OHCI0.6
   seems to make a incorrect modification as "PHY control register" is
   replaced by "GUID ROM register" which is unreasonable.

Regards,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Silicon Intergrated Systems Corporation
Tel: 886-3-5774922 x 4326
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	PAVW%mimi@magic.itg.ti.com
Sent:	Friday, October 04, 1996 6:28 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: How to handle data_error

From: Paul von Wupperfeld        PAVW
 
Subj: Re: How to handle data_error
 
Please unsubscribe me from this list.
 
Thank you,
 
Paul
 
-********** ORIGINAL MSG RECEIVED ON 10/03/96 AT 16:55 FOLLOWS **********-
 
-MSG M#=  2196420 FR=MSGO TO=PAVW   SENT=10/03/96  04:55 PM
     R#=175 ST=C DIV=0003 CC=00113 BY=MSGO AT=10/03/96 04:55 PM
 
To:      PAVW
 
From:    "Michael D. Johas Teener - CTO Firefly, Inc."  leew@austin.ibm.com
 
Subject: Re: How to handle data_error
 
**********
 
Via: MIMI 2.2 Gateway at Magic (TID DA386565 dated 3 Oct 96 14:34:52 -0700)
Subject: Re: How to handle data_error
From: "Michael D. Johas Teener - CTO Firefly, Inc." <mike@fireflyinc.com>
To: "Mourn, Richard" <RMOURN@COSSYMWEST.CO.SYMBIOS.COM>,
    "1394ohci-l" <1394ohci-l@austin.ibm.com>
X-Mailer: Cyberdog/1.1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
 
In general ...
 
>1) stop and allow firmware/software to figure out what is wrong (this is
how
>openHCI would handle it)
 
This *is* correct.
 
>2) retry the packet automatically just like a busied packet. (in this case
 
>should we use the maxRetries value used for Busied packets,  we may need
to
>define an interrupt  for this condition. Do we need to follow fairness for
 
>the remainder of the retries?
 
Please, no automatic retry of transactions unless you *really* know what
you are doing.
 
a) If it is write request, the responder does nothing other than report the
error. There may be corrupted data stored, but that's life in a pipelined
system. The driver needs to be notified in case this write has side
effects.
 
b) If it is a read response, the responder (sender of the packet) does
nothing other than (perhaps) log the error. The requester (receiver of the
packet) will typically retry the *entire* request. Depending on the
application, there may be side effects ... that's why the driver should be
notified, and perhaps even the higher level (SBP for instance) request
retried.
 
===================================================================
Michael D. Johas Teener
Chief Technical Officer, Firefly, Inc.
269 Mt. Herman Rd. #102, Scotts Valley, CA 95066-4000
phone: +1-408-461-4901           fax: +1-408-461-1394
email: mike@fireflyinc.com
===================================================================
From:	Calto Wong [cxw@philabs.research.philips.com]
Sent:	Friday, October 04, 1996 8:22 AM
To:	Hisato Shima
Cc:	PJohansson@aol.com; 1394taarchitecturewg; 1394ohci-l@austin.ibm.com; suters@natlab.research.philips.com; cxw@philabs.research.philips.com; txs@philabs.research.philips.com; caltow@ns.computer.net
Subject:	Re: Application Retries of DATA_ERROR

Hisato Shima wrote:
> > This error, unlike the various BUSY_? conditions that the LINK can handle
> > automatically, must be kicked back to the application for its handling.
> 
> I agree your comment as a concept, as well as an implementation
> guideline, but I have concern about how the 1394 formal service model
> treat this error.  I think this problem in service model generates
> confusion about error handling.

I don't know how this discussion got started again, but since it is
related to the "bad response packet" issue raised at the last 1394a
meeting, I would like to give some comments.

I think Peter and Hisato were dealing with two issues here, DATA_ERROR
in response packet, and DATA_ERROR in request packet:

================================
1. DATA_ERROR in response packet
================================
This seems to be the case Hisato was addressing.  I raised this issue
during the last 1394a WG meeting and subsequently posted a mail on the
reflector stating our view and solutions (retry/undo response) to this
problem.  We are particularly concerned about the side effect in case
an erroneous lock response was received, since it meant unconfirmed
resource (de)allocation may have occured.  Please refer to the mail
forwarded by Tom Suters for details.

1.1. The requesting application starts the transaction by instructing
     the requesting node to send a request packet.

1.2. The responding node receives the request packet, and implements a
     split or concatenated transaction by first sending ack_pending.

1.3. The requesting node waits for the response.

1.4. The responding node sends a response packet.

1.5. An error occurs in the data portion of the response packet.

1.6. The requesting node registers a data_CRC_error when the response
     packets arrives.  In this case:

     1.6.1. It terminates the transaction by sending a transaction
            data confirmation to the requesting application with
            a request status of DATA_ERROR.

     1.6.2. It sends an ack_data_error back to the responding node.

1.7. The responding node generates a transaction event indication of
     RESPONSE_ERROR to the node controller.

From the requesting application's point of view, the transaction
fails.  From the responding application's point of view, there is no
clue to any error except if the transaction event indication is
routed to it.  As Hisato pointed out, this needs not happen based on
the current 1394 service model.

If this error information does get to the responding application,
application-level retry of the response still does not help, since
the requesting application has already terminated the transaction
(unless the link layer state machine is modified.)  This was the
reason behind our recommendation:

- the responding application will undo the response if it gets a
  transaction event indication of RESPONSE_ERROR (resulting from
  data CRC error in the response packet)

- the responding application will retry the response if it gets a
  transaction event indication of ACKNOWLEDGE_MISSING (resulting
  from header error in the response packet)


===============================
2. DATA_ERROR in request packet
===============================
This seems to be the case Peter was addressing.

2.1. The requesting application starts the transaction by instructing
     the requesting node to send a request packet.

2.2. An error occurs in the data portion of the request packet.

2.3. The responding node registers a data_CRC_error when the request
     packet arrives, it will:

     2.3.1. Reasonally, ignore this request, as Peter suggested.
            However, Figure 7.2 and Section 7.3.3.2.2, does NOT
            explicitly say that transaction data indication will not
            be generated, so confusion is possible.

            Since a transaction data indication does not carry packet
            status, the responding application cannot be expected to
            respond differently according to the packet status.  If a
            response is returned, it will subsequently be discarded as
            unsolicited response by the requesting node since it will
            have terminated the transaction by then (see 1.4).

            A better solution to avoid confusion is not to initiate the
            indication at all. The 1394a WG can probably establish
            guidelines as to what the responding node should do if it
            registers a data_CRC_error (and, similarly, format_error) in
            the received request packet.

     2.3.2. Send an ack_data_error back to the requesting node.

2.4. The requesting node terminates the transaction by sending a
     transaction data confirmation to the requesting application with
     a response code of RESP_DATA_ERROR.  Based on the application
     model of the memory (side-effect or not), the requesting
     application can decide if a retry of the entire transaction
     solves the problem, as indicated by Peter.

     Since the requesting application receives an explicit transaction
     data confirmation indicating this error, there is no confusion
     about error handling, as suggested by Hisato.  The only confusion
     is how the responding node deals with requests with data error
     (2.3.1)


--
     Regards,
 
     Calto Wong
 
     Philips Research Briarcliff
     Room B.348, 345 Scarborough Road, Briarcliff Manor, NY10510, USA
     TEL   : +1 914 945 6382
     FAX   : +1 914 945 6556
     E-mail: cxw@philabs.research.philips.com
From:	PJohansson@aol.com
Sent:	Friday, October 04, 1996 9:03 AM
To:	cylin@sis.com.tw; 1394ohci-l@austin.ibm.com
Subject:	Re: PHY control/Node ID register

In a message dated 96-10-04 06:14:09 EDT, cylin@sis.com.tw (Chien-Yuh Lin)
writes:

<< 1) In 3.6, it said that "rdAddr field should be compared to the value
 expected because the PHY can automatically send a register, such as 
    the nodeID register, and thus replace the contents of the read
    before software can look at it". Who should do the comparison?-
    software or hardware? If done by software, then how to guarantee
    that software gets the desired data? If done by hardware, then
    the rdAddr field is redundant because rdAddr always equals to
    regAddr.
  >>

The comparison (and potential reread) is most easily done by software. This
is based on the fact that the quadlet read from the register is
self-consistent. That is, it may not contain the data requested, but it does
containn valid data. The software simply checks the index value of the PHY
register read and if not the expected register issues a reread.

The code snippet below is for a Pele implementation, but because of OpenHCI's
lineage, I think it's essentially similar.

      do {
         OUTQUAD(phyControl, READ_PHY | (i << 8));
         while (((phyControlImage = INQUAD(phyControl)) & PHY_READ_DONE) ==
0)
            ;
      } while ((phyControlImage & PHY_READ_ADDDR) != (i << 24));

Of course the assumption here is that in a (reasonably) short time, the
desired read succeeds!!! If there's some sort of PHY activity that prevents
this, the system undoubtedly has other problems...

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	cylin@sis.com.tw
Sent:	Tuesday, October 08, 1996 2:00 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: PHY control/Node ID register


In reply to the following PHY control/Node ID register question,

><< 1) In 3.6, it said that "rdAddr field should be compared to the value
> expected because the PHY can automatically send a register, such as 
>    the nodeID register, and thus replace the contents of the read
>    before software can look at it". Who should do the comparison?-
>    software or hardware? If done by software, then how to guarantee
>    that software gets the desired data? If done by hardware, then
>    the rdAddr field is redundant because rdAddr always equals to
>    regAddr.
>  >>
>

Peter Johansson writes:

>The comparison (and potential reread) is most easily done by software. This
>is based on the fact that the quadlet read from the register is
>self-consistent. That is, it may not contain the data requested, but it does
>containn valid data. The software simply checks the index value of the PHY
>register read and if not the expected register issues a reread.
>
>The code snippet below is for a Pele implementation, but because of OpenHCI's
>lineage, I think it's essentially similar.
>
>      do {
>         OUTQUAD(phyControl, READ_PHY | (i << 8));
>         while (((phyControlImage = INQUAD(phyControl)) & PHY_READ_DONE) ==
>0)
>            ;
>      } while ((phyControlImage & PHY_READ_ADDDR) != (i << 24));
>
>Of course the assumption here is that in a (reasonably) short time, the
>desired read succeeds!!! If there's some sort of PHY activity that prevents
>this, the system undoubtedly has other problems...
>

If the comparison is done by software, then phyRegRcvd bit in the
intEvent register will be set when a PHY register is received, no
matter is automatically sent or not. Therefore, software needs to
read the phyControl register only when phyRegRcvd interrupt is
detected. This may eliminate the need to have the read succeeded in
a short time (,right?).

Another problem w/ phyControl register is rdDone bit. In OHCI0.6,
rdDone is not software writable, and it is not specified when this
bit is cleared. A reasonable solution may be, if the above implemention,
i.e., set phyRegRcvd whenever PHY register is received, is adopted,
then rdDone is cleared by hardware when phyRegRcvd is cleared. This
however makes rdDone redundent. Any better idea?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Silicon Intergrated Systems Corporation
Tel: 886-3-5774922 x 4326
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Tuesday, October 08, 1996 7:23 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; cylin@sis.com.tw
Subject:	When to update DBDMA status (xferStatus field)


According to "IEEE 1394-1995 High Performance Serial Bus Implementation
Examples" by Peter Teng in 1394 OpenHCI Developers Conference. In Slide 21
says: 
"DBDMA Implementation
*...............................................
 ...............................................
 .......... the sequence of execution is
* processes the command, updates the status bits
                         ^^^^^^^^^^^^^^^^^^^^^^^
* the DBDMA engine waits until the condition is false
* interrupt sends to the host, and DBDMA engine jumps
  to the specified branch address"

In IRDMA, if we set both wait and branch bits to S1(Cycle time matches the
eCycle). the BT bit of status bits may not be updated correctly.
  
My reason is when processing the command, S1 condition not match, so BT will
be set to zero(status also be updated). But when S1 condition is waited to
be matched, the BT bit shall become TRUE. Since the BT has been updated,
application cannot see the correct status.

Should we update the status after all wait,interrupt and branch are evaluated?
Thanks for your answer.

Shu-Ming Liu
 
Shu-Ming Liu   
Software Engineer
Software Design Department
Silicon Integrated Systems Corp.
Phone 886-35-774922 ext 4157
Fax   886-35-790651
Email shuming@sis.com.tw
Address: No 16, Creation Rd 1, 
         Science-based Industrial Park,
         Hsinchu, Taiwan

From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Wednesday, October 09, 1996 12:47 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cylin@sis.com.tw; cmlin@sis.com.tw
Subject:	How does software know the GRU Status (OHCI v0.6)?


In clause 6.4.1.1:
"No general purpose status bits (s7...s0) are allocated. Interrupt, branch,
and wait mask/value bits are not implemented."

There is no GRU interrupt defined in IntEvent register also. My question is
how does software know the packet's incoming and process it?

Thanks for your answers.

Shu-Ming Liu 
Shu-Ming Liu   
Software Engineer
Software Design Department
Silicon Integrated Systems Corp.
Phone 886-35-774922 ext 4157
Fax   886-35-790651
Email shuming@sis.com.tw
Address: No 16, Creation Rd 1, 
         Science-based Industrial Park,
         Hsinchu, Taiwan

From:	PAVW%mimi@magic.itg.ti.com
Sent:	Wednesday, October 09, 1996 6:17 AM
To:	1394ohci-l@austin.ibm.com
Subject:	When to update DBDMA status (xferStatus field)

From: Paul von Wupperfeld        PAVW
 
Subj: When to update DBDMA status (xferStatus field)
 
PLEASE UNSUBSCRIBE ME FROM THIS LIST!  I HAVE SENT IN NUMEROUS REQUESTS; IF
NO ONE CAN DO THIS FOR ME, COULD SOMEONE PLEASE BE KIND ENOUGH TO TELL ME
HOW TO DO IT MYSELF.
 
-********** ORIGINAL MSG RECEIVED ON 10/08/96 AT 22:20 FOLLOWS **********-
 
-MSG M#=  2462095 FR=MSGO TO=PAVW   SENT=10/08/96  10:20 PM
     R#=005 ST=C DIV=0003 CC=00113 BY=MSGO AT=10/08/96 10:20 PM
 
To:      PAVW
 
From:    Shu-Ming Liu  leew@austin.ibm.com
 
Subject: When to update DBDMA status (xferStatus field)
 
**********
 
Via: MIMI 2.2 Gateway at Magic (TID DA560947 dated Wed, 09 Oct 1996 10:23:12
  +0800)
X-Sender: shuming@axp.sis.com.tw
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 1394ohci-l@austin.ibm.com
From: Shu-Ming Liu <sis.com.tw@sis.com.tw>
Subject: When to update DBDMA status (xferStatus field)
Cc: cmlin@sis.com.tw, cylin@sis.com.tw
 
 
According to "IEEE 1394-1995 High Performance Serial Bus Implementation
Examples" by Peter Teng in 1394 OpenHCI Developers Conference. In Slide 21
says:
"DBDMA Implementation
*...............................................
 ...............................................
 .......... the sequence of execution is
* processes the command, updates the status bits
                         ^^^^^^^^^^^^^^^^^^^^^^^
* the DBDMA engine waits until the condition is false
* interrupt sends to the host, and DBDMA engine jumps
  to the specified branch address"
 
In IRDMA, if we set both wait and branch bits to S1(Cycle time matches the
eCycle). the BT bit of status bits may not be updated correctly.
 
My reason is when processing the command, S1 condition not match, so BT will
be set to zero(status also be updated). But when S1 condition is waited to
be matched, the BT bit shall become TRUE. Since the BT has been updated,
application cannot see the correct status.
 
Should we update the status after all wait,interrupt and branch are evaluated?
Thanks for your answer.
 
Shu-Ming Liu
 
Shu-Ming Liu
Software Engineer
Software Design Department
Silicon Integrated Systems Corp.
Phone 886-35-774922 ext 4157
Fax   886-35-790651
Email shuming@sis.com.tw
Address: No 16, Creation Rd 1,
         Science-based Industrial Park,
         Hsinchu, Taiwan
From:	PAVW%mimi@magic.itg.ti.com
Sent:	Wednesday, October 09, 1996 6:20 AM
To:	1394ohci-l@austin.ibm.com
Subject:	unsubscribe

From: Paul von Wupperfeld        PAVW
 
Subj: unsubscribe
 
unsubscribe leew@austin.ibm.com
From:	klashman@meow.East.Sun.COM
Sent:	Wednesday, October 09, 1996 1:45 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: How does software know the GRU Status (OHCI v0.6)?

>From: Shu-Ming Liu <sis.com.tw@sis.com.tw>
>
>In clause 6.4.1.1:
>"No general purpose status bits (s7...s0) are allocated. Interrupt, branch,
>and wait mask/value bits are not implemented."
>
>There is no GRU interrupt defined in IntEvent register also. My question is
>how does software know the packet's incoming and process it?

6.4.1.1 means that there are no 'conditional' interrupts.
However, you can still set the DBDMA command to always_interrupt or
never_interrupt since those don't require status bits.
See table 5-7 in 5.3.1.4.

Diana
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From:	Peter Teng [pteng@rockie.nsc.com]
Sent:	Thursday, October 10, 1996 11:45 PM
To:	Shu-Ming Liu; 1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; cylin@sis.com.tw
Subject:	Re: When to update DBDMA status (xferStatus field)

Hi,

    Sorry for the long delay in replying your question.

At 10:23 AM 10/9/96 +0800, Shu-Ming Liu wrote:
>
>According to "IEEE 1394-1995 High Performance Serial Bus Implementation
>Examples" by Peter Teng in 1394 OpenHCI Developers Conference. In Slide 21
>says: 
>"DBDMA Implementation
>*...............................................
> ...............................................
> .......... the sequence of execution is
>* processes the command, updates the status bits
>                         ^^^^^^^^^^^^^^^^^^^^^^^
>* the DBDMA engine waits until the condition is false
>* interrupt sends to the host, and DBDMA engine jumps
>  to the specified branch address"
>

The status bits are referring to the xferstatus and rescount. The s0..7 and
channel status are all evaluated in real time. Sorry for the confusion.

>In IRDMA, if we set both wait and branch bits to S1(Cycle time matches the
>eCycle). the BT bit of status bits may not be updated correctly.
>  
>My reason is when processing the command, S1 condition not match, so BT will
>be set to zero(status also be updated). But when S1 condition is waited to
>be matched, the BT bit shall become TRUE. Since the BT has been updated,
>application cannot see the correct status.
>
>Should we update the status after all wait,interrupt and branch are evaluated?
>Thanks for your answer.
>

best regards,
Peter Chu Tin Teng
Personal Systems Strategic Marketing Segment
National Semiconductor
2900 Semiconductor Drive
Mail Stop D1600
Santa Clara, CA 95052
Tel: (408)721-6594
Fax: (408)721-4988
Email: pteng@rockie.nsc.com
Skytel: (800)7598352 pin#4123089

From:	Peter Teng [pteng@rockie.nsc.com]
Sent:	Friday, October 11, 1996 11:44 PM
To:	cylin@sis.com.tw; 1394ohci-l@austin.ibm.com
Subject:	Re: PHY control/Node ID register

At 04:59 PM 10/8/96 +0800, Chien-Yuh Lin wrote:
>
>In reply to the following PHY control/Node ID register question,
>
><< 1) In 3.6, it said that "rdAddr field should be compared to the value
> expected because the PHY can automatically send a register, such as 
>    the nodeID register, and thus replace the contents of the read
>    before software can look at it". Who should do the comparison?-
>    software or hardware? If done by software, then how to guarantee
>    that software gets the desired data? If done by hardware, then
>    the rdAddr field is redundant because rdAddr always equals to
>    regAddr.

Actually, For the current implementation, there should not be any register
read (unsolicited)  automatically coming from the PHY except register zero.
But the register zero is autonomously routed to the node identification
register instead. But for 1394A (whatever it may become), the software
should always compare the content of rdaddr with regaddr to ensure there is
no unsolicited register read. 

>
>If the comparison is done by software, then phyRegRcvd bit in the
>intEvent register will be set when a PHY register is received, no
>matter is automatically sent or not. Therefore, software needs to
>read the phyControl register only when phyRegRcvd interrupt is
>detected. This may eliminate the need to have the read succeeded in
>a short time (,right?).

The phyregrcvd bit in the intevent register is only set if the corresponding
bit in the intmask register is set. So choices are given for polling (by
keep on reading) or interrupt event driven.

>Another problem w/ phyControl register is rdDone bit. In OHCI0.6,
>rdDone is not software writable, and it is not specified when this
>bit is cleared. A reasonable solution may be, if the above implemention,
>i.e., set phyRegRcvd whenever PHY register is received, is adopted,
>then rdDone is cleared by hardware when phyRegRcvd is cleared. This
>however makes rdDone redundent. Any better idea?
>

The rdDone bit is not cleared until another register write is requested.


happy computing? 
and best regards,
Peter Chu Tin Teng
Personal Systems Strategic Marketing Segment
National Semiconductor
2900 Semiconductor Drive
Mail Stop D1600
Santa Clara, CA 95052
Tel: (408)721-6594
Fax: (408)721-4988
Email: pteng@rockie.nsc.com
Skytel: (800)7598352 pin#4123089

From:	cmlin@sis.com.tw
Sent:	Monday, October 14, 1996 10:57 AM
To:	1394ohci-l@austin.ibm.com
Cc:	SISUSA!SISUSA!MAIW@siscorp.attmail.com
Subject:	The questions about the OHCI spec (ver:0.6)

Hi,

  Here are questions about the OHCI spec (ver:0.6). 


1. Introduction

1). OHCI 1.4.12 mentions that Link should receive Isoch packet at all 
     times, and explains that Link may receive a cycle start packet
     with CRC error, causes OHCI can't switch to Isoch cycle successfully.
     (a). Since we should receive Isoch packet at all times, how to
           guarantee the Asyn. bandwith?
     (b). Can we transmit Isoch packet in Async period ?
     (c). The bit "isoActive" in Node ID register should be redefined
            when we should receive Isoch packets at all times.

2).OHCI p.5 Link mentioned,
   [It includes the following features....
    * Supports separate physical response stream.
   What does it actually mean, does it relate to PRSU ? Or it relates
   to the concatenate and split transaction in 1394 spec. ? 


3. 1394 Open HCI Registers


    1). To gaurantee each cycle accessing the PHY control register can
          properly transfer to the PHY chip.  The hardware will retry
          another cycle  to access the PHY control register when the
          previous cycle is not complete to transfer to the PHY chip. 
          Is it right?

    2). OHCI 3.3
         "linkON" field description:  S.W must set this bit when ...
         and force a bus reset? Was the bus reset originated by H.W or
         S.W?

    3). OHCI 3.3
         mentions that no bits in control register are updated
         autonomously by H.W, and some bits are cleared automatically
         by a bus reset or other events.  It seems confliciting some
         fields are autonomously updated by H.W, right?

     4). OHCI 3.3~
          What is the purpose to access incoming PHY packets?  If
          "rcvPhyPkt" bit is set, will OHCI accept all PHY packets on
          the bus or accept only the PHY packet belong to it?

    5). OHCI 3.4~
         When will the PHY report the cable power status to the LINK?
         Will the PHY automatically send the register 0 to the LINK  through
          status transfer after detecting cable_power_fail?  If yes,
          the driver how to know the register 0 has been transferred. 
          In the cable-power-fail case, does a bus reset initiate in
          the bus? If yes, who is the initiator?  the driver, the PHY
          chip or the parent node of this node?


4. Interrupts

    1). In Page 44. PSOutOfRetries should be defined in Interrupt Register.

    2). The field of "phyInt" in Table 4.1 means that the phy requests
         an interrupt through a status transfer.  What is the interrupt event? 
         Is it the event of "state time out"?


5. DMA Operation

    1). Table 5.3 is not compliant to Table 2.3.

    2). Which address will be used in the STORE_QUAD/LOAD_QUAD
          command? Address offset or Key_REGs address (as given in
          table 5.3)?


6. DMA Specifics

   1). The definition IRAEventCycle & IRAConfig(P.54 6.5.3) are
        different with IR DMA Configuration Registers (P.23 3.10).

   2). What is the ack_type_error condition, do header CRC error and 
          tcode error belong to this condition?

   3). Is there any condition that Link should discard the incoming
         packet and return no acknoledge ?

   4). Ack_data_error and ack_type_error for asynchronous transmission,
        When Link receive a packet and find that it has data CRC
        error, then Link will return ack_data_error,
       (a). should Link discard this packet ?
       (b). If not, what will driver do with this packet? And, how about if
             this is a request packet, will driver return a response packet ?
       (c). what shall Link do if it found the packet was a type_error
             one? Should it discard the packet ?

   5). Do the operations of write and swap in the hware-implemented  
        CSRs of bus management  need to be removed in the description in
         section 6.4.4?


7. Packet Formats

    1). When transmitting Asyn packet, OHCI will decide the data length
         in terms of the buffers specified by driver (DBDMA commands),
         why in table 7-3 block data field says, if the dataLength ==
         0, no data should be written into the FIFO ?

    2). Same question as 1. In table 7-4 Asyn. receive, should we discard
         all data field if the dataLength is zero ?

    3). In table 7-4, what is the definition of the field of errCode ?


Annex A. P1394 Enhancements Required for 1394 Open HCI

    1). the sentence : the root PHY will have phy_ID of zero.... in
         OHCIv05 why it is canceled in OHCIv06 ?


Thanks for your help,


======================================
Chi-Ming Lin
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp. (SiS)
Phone  : 886-3-5774922 ext. 4324
Fax    : 886-3-5790651
E-mail : cmlin@sis.com.tw
======================================

From:	cylin@sis.com.tw
Sent:	Monday, October 14, 1996 9:01 PM
To:	Peter Teng; 1394ohci-l@austin.ibm.com
Subject:	Re: PHY control/Node ID register


According to Peter Teng's reply at 11 Oct 1996 23:44:01 -0700:

>Actually, For the current implementation, there should not be any register
>read (unsolicited)  automatically coming from the PHY except register zero.
>But the register zero is autonomously routed to the node identification
>register instead. But for 1394A (whatever it may become), the software
>should always compare the content of rdaddr with regaddr to ensure there is
>no unsolicited register read. 
>

It's ok so far if software doesn't do the comparison, but may not be 
true for 1394a. Here is another relevant question: 
What happens if software intends to read register zero? If register 
zero is automatically routed to NodeID register, then software could 
be trapped in an infinite polling loop... I think it's better that
hardware put whatever (register) it gets to PHY Control register (
this violates OHCI0.6 however) and software always makes a comparison
to decide what to do with the PHY information obtained. 

>>Another problem w/ phyControl register is rdDone bit. In OHCI0.6,
>>rdDone is not software writable, and it is not specified when this
>>bit is cleared. A reasonable solution may be, if the above implemention,
>>i.e., set phyRegRcvd whenever PHY register is received, is adopted,
>>then rdDone is cleared by hardware when phyRegRcvd is cleared. This
>>however makes rdDone redundent. Any better idea?
>>
>
>The rdDone bit is not cleared until another register write is requested.
>
Is register write referred to the PCI register write? Why not PCI
register read?- since PCI register read means the register contents
is available to software.

Thanks for your help.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Silicon Intergrated Systems Corporation
Tel: 886-3-5774922 x 4326
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	Peter Teng [pteng@rockie.nsc.com]
Sent:	Monday, October 14, 1996 10:07 PM
To:	cylin@sis.com.tw; 1394ohci-l@austin.ibm.com
Subject:	Re: PHY control/Node ID register

>According to Peter Teng's reply at 11 Oct 1996 23:44:01 -0700:
>
>>Actually, For the current implementation, there should not be any register
>>read (unsolicited)  automatically coming from the PHY except register zero.
>>But the register zero is autonomously routed to the node identification
>>register instead. But for 1394A (whatever it may become), the software
>>should always compare the content of rdaddr with regaddr to ensure there is
>>no unsolicited register read. 
>>
>
>It's ok so far if software doesn't do the comparison, but may not be 
>true for 1394a. Here is another relevant question: 
>What happens if software intends to read register zero? If register 
>zero is automatically routed to NodeID register, then software could 
>be trapped in an infinite polling loop... I think it's better that
>hardware put whatever (register) it gets to PHY Control register (
>this violates OHCI0.6 however) and software always makes a comparison
>to decide what to do with the PHY information obtained. 

Good question. But first, why does the software want to read the register zero?
Since the software knows that the content of register zero is always available 
somewhere else, it should not even try to do so (somebody may disagree to
this). 
The intention was if bus reset occurs, the HCI has to parse the unsolicited 
register zero and route them to the specfic registers. So there is no need to 
store them again in the PHY control register. But from the hardware's point of 
view, I would agree with you that hardware put whatever received into the PHY
control register to save additinal gates in prohibiting the reception of
register
zero into PHY control register. 

>>>Another problem w/ phyControl register is rdDone bit. In OHCI0.6,
>>>rdDone is not software writable, and it is not specified when this
>>>bit is cleared. A reasonable solution may be, if the above implemention,
>>>i.e., set phyRegRcvd whenever PHY register is received, is adopted,
>>>then rdDone is cleared by hardware when phyRegRcvd is cleared. This
>>>however makes rdDone redundent. Any better idea?
>>>
>>
>>The rdDone bit is not cleared until another register write is requested.
>>
>Is register write referred to the PCI register write? Why not PCI
>register read?- since PCI register read means the register contents
>is available to software.
>

I meant another write to PHY control register in requesting the PHY read
function.

Peter Chu Tin Teng
Personal Systems Strategic Marketing Segment
National Semiconductor
2900 Semiconductor Drive
Mail Stop D1600
Santa Clara, CA 95052
Tel: (408)721-6594
Fax: (408)721-4988
Email: pteng@rockie.nsc.com
Skytel: (800)7598352 pin#4123089

From:	sganjooi@central.fmi.fujitsu.com
Sent:	Friday, October 18, 1996 3:38 PM
To:	1394ohci-l@austin.ibm.com
Cc:	sganjooi@central.fmi.fujitsu.com
Subject:	1394_OHCI_fmi_Q&A_LOG1

Hi,
 
I have some question on OHCI, and your feedback is greatly
appreciated.
 
        1) What are the consequences of merging the RQTF and
           RSTF into one async. TF ?
 
        2) The reqTxEnable, respTxEnable, and isoTxEnable bits
           in the control register all refer to cmd reset.
           What is cmd reset ?
 
        3) How do i use the reqTxEnable, and respTxEnable, if
           there is only one Async. Transmit FIFO?
 
        4) The isoTxEnable bit in the control register refers to
           cycle start messages. Is the cycle start message the
           same as cycle start packet ?
           If so, then what is the difference between the isoTxEnable
           bit and cycleMaster bit ?
 
        5) Please clarify the linkOn bit in the control register.
 
 
 
Thanks,
Sean Ganjooi
From:	cylin@sis.com.tw
Sent:	Tuesday, October 29, 1996 12:42 AM
To:	1394ohci-l@austin.ibm.com
Cc:	shuming@sis.com.tw; cmlin@sis.com.tw
Subject:	STORE/LOAD_QUAD w/ KEY_STREAM/SYSTEM in DBDMA

Hi, all:

I have some questions about DBDMA. In OHCI0.6, KEY_STREAMn and 
KEY_SYSTEM are supported for STORE_QUAD and LOAD_QUAD commands,

1) In what occasion will the two commands w/ either of these two
   keys be used?

2) What should be done for this kind of commands?- Initiates
   a PCI read/write cycle with the data and address given in the
   command? This action does not make sense for LOAD_QUAD command
   since the data obtained in the PCI read cycle will be written 
   back later through a PCI write.

Another question is about the STORE/LOAD_QUAD command when the
key assigned is KEY_REGS- what address will be given in the address
field? Address offset or KEY_REGS address (as given in Table 5-3)?

Thanks for your help,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Silicon Intergrated Systems Corporation
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	Bob Beims [RWBC70@WACCVM.corp.mot.com]
Sent:	Tuesday, October 29, 1996 1:08 PM
To:	1394OHCI-L@austin.ibm.com
Subject:	info

info
help
From:	wjshieh@sis.com.tw
Sent:	Thursday, October 10, 1996 8:55 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; shuming@sis.com.tw; cylin@sis.com.tw; daisy@sis.com.tw; shchuang@sis.com.tw; wjshieh@sis.com.tw
Subject:	about the isochronous receive mode

Hi,

According to "Software Overview of 1394 OpenHCI" by
John Nels Fuller in 1394 OpenHCI Developers Conference.
In slide 29 says :
"Isochronous Receive(IR)
 * Can use these modes
   - Buffer fill mode (like GRU)
   - Packet / buffer mode with headers
   - packet / buffer mode without headers"

What is the difference between "buffer fill mode" and
"packet / buffer mode with headers"? The receiving of
zero padding? Which mode uses key_stream0?

Thanks for your help,
======================================
Whieh-Jen Shieh
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp. (SiS)
Phone  : 886-3-5774922 ext. 4314
Fax    : 886-3-5790651
E-mail : wjshieh@sis.com.tw
======================================

From:	John Nels Fuller
Sent:	Thursday, October 31, 1996 11:47 AM
To:	'1394ohci-l@austin.ibm.com'; 'wjshieh@sis.com.tw'
Cc:	'cmlin@sis.com.tw'; 'shuming@sis.com.tw'; 'cylin@sis.com.tw'; 'daisy@sis.com.tw'; 'shchuang@sis.com.tw'
Subject:	RE: about the isochronous receive mode

In buffer fill mode packets are received into a buffer until that buffer
is completely full.  For example:
<header for packet 1><data for packet 1><status/timestamp for packet
1>...<header for packet n>
	next buffer:
<data for packet n><status/timestamp for packet n> ...

In packet per buffer mode exactly one packet is stored in each buffer,
perhaps leaving unused space at the end of the buffer.  The header for a
packet always comes at the beginning of the described buffer, unlike
buffer fill mode in which the beginning of the buffer just gets what is
next in the input stream.

Note:  For the packet per buffer mode a buffer is described by a group
of INPUT_* commands ending with an INPUT_LAST.  For buffer fill mode a
buffer is described by a single INPUT_* command.


>----------
>From: 	wjshieh@sis.com.tw[SMTP:wjshieh@sis.com.tw]
>Sent: 	Thursday, October 10, 1996 7:54 PM
>To: 	1394ohci-l@austin.ibm.com
>Cc: 	cmlin@sis.com.tw; shuming@sis.com.tw; cylin@sis.com.tw;
>daisy@sis.com.tw; shchuang@sis.com.tw; wjshieh@sis.com.tw
>Subject: 	about the isochronous receive mode
>
>Hi,
>
>According to "Software Overview of 1394 OpenHCI" by
>John Nels Fuller in 1394 OpenHCI Developers Conference.
>In slide 29 says :
>"Isochronous Receive(IR)
> * Can use these modes
>   - Buffer fill mode (like GRU)
>   - Packet / buffer mode with headers
>   - packet / buffer mode without headers"
>
>What is the difference between "buffer fill mode" and
>"packet / buffer mode with headers"? The receiving of
>zero padding? Which mode uses key_stream0?
>
>Thanks for your help,
>======================================
>Whieh-Jen Shieh
>Design Engineer
>Basic Technology Group
>Silicon Integrated Systems Corp. (SiS)
>Phone  : 886-3-5774922 ext. 4314
>Fax    : 886-3-5790651
>E-mail : wjshieh@sis.com.tw
>======================================
>
>
From:	Dream Ku [Dream_Ku@via.com.tw]
Sent:	Thursday, October 31, 1996 7:28 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Add these name to OHCI reflector


 Company name : VIA TECHNOLOGIES, INC  
 Address : 8F, 533, CHUNG-CHENG RD., HSIN-TIEN, TAIPEI, TWIWAN, R.O.C. 
 Phone : 886-2-2185452 FAX : 886-2-2185453 
 ---------------------------------------------------------------------------

 
 Please add the following e-mail list to your 1394ohci-l@austin.ibm.com
reflector.
 
 enoch@via.com.tw
 min@via.com.tw
 huang@via.com.tw
 
 Thank you for your help.
 
 VIA, Dream
From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Thursday, October 31, 1996 9:02 PM
To:	1394ohci-l@austin.ibm.com
Subject:	About the GRU receive mode

Hi, 

  I want to change the topic to GRU receive mode.

  According to "Software Overview of 1394 OpenHCI" by
  John Nels Fuller in 1394 OpenHCI Developers Conference.
  In slide 19 says :
  "GRU
   . Packets concatenated in buffer
   . Packets may cross buffer boundaries"
     
  In slide 20 says:
  "GRU DBDMA Cmd Queue
  CommandPtr
  Start: INPUT_MORE key=bu I(packet) br(always)=Next1 Ad=buffer1 cnt=length1
  Next1: INPUT_MORE key=bu I(packet) br(always)=Next2 Ad=buffer2 cnt=length2
  Next2: INPUT_MORE key=bu I(packet) br(always)=Next3 Ad=buffer3 cnt=length3
  Next3: STOP"

  Since more than one packets can be concatenated in one buffer. If we can
not expect what kind of packet will received in this time. We must
dynamically to decide the next address in the buffer to receive the packet. 

  So I guess after each packet has been received, we must execute a stop
command. When Interrupt Service Routine get the asynchRX, it must calculate
the packet length and then rewrite the STOP to next INPUT_* command. Then
set wake bit.

  I want to know if there is more simple and efficient method to achieve it
because I regard the sample code in slide 20 can receive one packet each
buffer. Could you please give me some commants?   

  Thanks for your answer.

      
***************************************************************
*Shu-Ming Liu                                                 *
*Software Engineer                                            *
*Software Design Department                                   *
*Silicon Integrated Systems Corp.                             *
*Phone 886-35-774922 ext 4157                                 *
*Fax   886-35-790651                                          *
*mailto shuming@sis.com.tw                                     *
*Address: No 16, Creation Rd 1,                               *
*         Science-based Industrial Park,                      *
*         Hsinchu, Taiwan                                     *
***************************************************************

From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Sunday, November 03, 1996 9:04 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; cylin@sis.com.tw; wjshieh@sis.com.tw
Subject:	RE: about the isochronous receive mode

Hi, all,

  Here I still have some questions need to be clarified.

At 11:46 AM 10/31/96 -0800, John Nels Fuller wrote:
>In buffer fill mode packets are received into a buffer until that buffer
>is completely full.  For example:
><header for packet 1><data for packet 1><status/timestamp for packet
>1>...<header for packet n>
>	next buffer:
><data for packet n><status/timestamp for packet n> ...
>
>In packet per buffer mode exactly one packet is stored in each buffer,
>perhaps leaving unused space at the end of the buffer.  The header for a
>packet always comes at the beginning of the described buffer, unlike
>buffer fill mode in which the beginning of the buffer just gets what is
>next in the input stream.
>
>Note:  For the packet per buffer mode a buffer is described by a group
>of INPUT_* commands ending with an INPUT_LAST.  For buffer fill mode a
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  If the buffer is big enough to fill in a packet, why should we use more
than one DBDMA commands instead of just using one INPUT_MORE or one INPUT_LAST?


>buffer is described by a single INPUT_* command.
                          ^^^^^^^^^^^^^^
  I don't know if INPUT_* represents INPUT_MORE? If not, I think only
INPUT_MORE can be used in buffer fill mode. Because according to 1394 OHCI
Spec 0.6, Page 38 says: "INPUT_LAST: When the end of a packet is detected,
the command is completed." The following packets cannot be received
continuously, except that we use another INPUT_*, right?  



>>From: 	wjshieh@sis.com.tw[SMTP:wjshieh@sis.com.tw]
>>Sent: 	Thursday, October 10, 1996 7:54 PM
>>To: 	1394ohci-l@austin.ibm.com

>>Hi,
>>
>>According to "Software Overview of 1394 OpenHCI" by
>>John Nels Fuller in 1394 OpenHCI Developers Conference.
>>In slide 29 says :
>>"Isochronous Receive(IR)
>> * Can use these modes
>>   - Buffer fill mode (like GRU)

  According to 1394 OHCI Spec 0.6, clause 6.4.1 on Page 49, which says:
"Data chaining across channel commands is not supported." Why can buffer
fill mode be used in GRU? I think that a packet may be scattered in two
buffers in buffer fill mode because we can not predict which kind of packet
will be received.


***************************************************************
*Shu-Ming Liu                                                 *
*Software Engineer                                            *
*Software Design Department                                   *
*Silicon Integrated Systems Corp.                             *
*Phone 886-35-774922 ext 4157                                 *
*Fax   886-35-790651                                          *
*mailto shuming@sis.com.tw                                     *
*Address: No 16, Creation Rd 1,                               *
*         Science-based Industrial Park,                      *
*         Hsinchu, Taiwan                                     *
***************************************************************

From:	Jimmy [min@via.com.tw]
Sent:	Thursday, November 07, 1996 12:41 AM
To:	1394ohci-l@austin.ibm.com
Subject:	About DBDMA command descriptor

Hi, all:

	The DBDMA command entry is a 16 bytes data block at 5.3 of draft 0.75.
Is the data block is big endian or little endian presentation ? Is there
a control bit to control the OPENHCI controller to fetch the command
with a little endian or big endian format ?

*********************************
* Jin-min Lin
* Software Engineer
* VIA Technologies
* Phone  : 886-2-2185452 ext 363
* FAX    : 886-2-2185453
* E-Mail : min@via.com.tw
*********************************
From:	John Nels Fuller
Sent:	Thursday, November 07, 1996 8:00 AM
To:	'1394ohci-l@austin.ibm.com'; 'min@via.com.tw'
Subject:	RE: About DBDMA command descriptor

The OpenHCI controller is assumed to be on a 32-bit bus and DBDMA
commands are assumed to be on 16-byte boundaries so that this data
structure is endian neutral.  The structure is defined with most
significant bit on the left and the least significant bit on the right.

That said, some systems (PowerMac for example) which are natively big
endian do byte swapping at the processor to PCI bridge which means
software will have to swizzle the bytes.  However, the HC just fetches
quadlets and doesn't need to know the byte ordering within it for the HC
data structures.

>----------
>From: 	Jimmy[SMTP:min@via.com.tw]
>Sent: 	Thursday, November 07, 1996 12:40 AM
>To: 	1394ohci-l@austin.ibm.com
>Subject: 	About DBDMA command descriptor
>
>Hi, all:
>
>	The DBDMA command entry is a 16 bytes data block at 5.3 of draft 0.75.
>Is the data block is big endian or little endian presentation ? Is there
>a control bit to control the OPENHCI controller to fetch the command
>with a little endian or big endian format ?
>
>*********************************
>* Jin-min Lin
>* Software Engineer
>* VIA Technologies
>* Phone  : 886-2-2185452 ext 363
>* FAX    : 886-2-2185453
>* E-Mail : min@via.com.tw
>*********************************
>
From:	Jimmy [min@via.com.tw]
Sent:	Friday, November 08, 1996 12:47 AM
To:	1394ohci-l@austin.ibm.com
Subject:	DBDMA for GRU

Hi, everyone

	I have some question for GRU.

	According 6.4.1 of OpenHCI draft 0.75, "Data chaining across channel
commands is not supported." And the header should always be saved into
memory for GRU to inform the software what kind packet has been
received.

	It seems that only OUTPUT_LAST and KEY_STREAM0 (packet-per-buffer with
headers) can be supported for GRU to receive data. And its reqCount
field must larger than or equal to the maximum packet length + 5
quadlets.

	Should OUTPUT_MORE be executed same as OUTPUT_LAST in GRU ? And should
KEY_STREAM1, KEY_STREAM2 and KEY_STREAM3 be executed same as KEY_STREAM0
in GRU ? Or these command should be treated as a error condition ?

Thanks

*********************************
* Jin-min Lin
* Software Engineer
* VIA Technologies
* Phone  : 886-2-2185452 ext 363
* FAX    : 886-2-2185453
* E-Mail : min@via.com.tw
*********************************
From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Friday, November 08, 1996 3:18 AM
To:	min@via.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: DBDMA for GRU

At 04:47 PM 11/8/96 +0800, you wrote:
>Hi, everyone
>
>	I have some question for GRU.
>
>	According 6.4.1 of OpenHCI draft 0.75, "Data chaining across channel
>commands is not supported." And the header should always be saved into
>memory for GRU to inform the software what kind packet has been
>received.
>
>	It seems that only OUTPUT_LAST and KEY_STREAM0 (packet-per-buffer with
                           ^^^^^^^^^^^ -> should be INPUT_LAST
>headers) can be supported for GRU to receive data. And its reqCount
>field must larger than or equal to the maximum packet length + 5
>quadlets.
>
>	Should OUTPUT_MORE be executed same as OUTPUT_LAST in GRU ? And should
               ^^^^^^^^^^^ -> INPUT_MORE       ^^^^^^^^^^^ -> INPUT_LAST
  
  IMHO, I think only INPUT_LAST can be used in GRU. Spec. says "input packet
defined by zero or more INPUT_MOREs followed by INPUT_LAST"

>KEY_STREAM1, KEY_STREAM2 and KEY_STREAM3 be executed same as KEY_STREAM0
>in GRU ? Or these command should be treated as a error condition ?

  According to OHCI Draft 0.75 page 33, ".. only KEY_STREAM0 is implemented
for asynchrounous receive...".

>
>Thanks
>
>*********************************
>* Jin-min Lin
>* Software Engineer
>* VIA Technologies
>* Phone  : 886-2-2185452 ext 363
>* FAX    : 886-2-2185453
>* E-Mail : min@via.com.tw
>*********************************
>
>
>
***************************************************************
*Shu-Ming Liu                                                 *
*Software Engineer                                            *
*Software Design Department                                   *
*Silicon Integrated Systems Corp.                             *
*Phone 886-35-774922 ext 4157                                 *
*Fax   886-35-790651                                          *
*mailto shuming@sis.com.tw                                     *
*Address: No 16, Creation Rd 1,                               *
*         Science-based Industrial Park,                      *
*         Hsinchu, Taiwan                                     *
***************************************************************

From:	Jimmy [min@via.com.tw]
Sent:	Friday, November 08, 1996 7:12 PM
To:	1394ohci-l@austin.ibm.com
Subject:	rcv bit in Control register

Hi, everyone :

	There are 3 bits in Control register to control packet receiving. They
are rcvEnable, rcvPhyPkt and rcvSelfID. If the rcvEnable is disabled,
will the physical packet and the self identify packet be received ?

	Should the OpenHCI controller put the physical packet to self identify
buffer or put it to GRU ?

*********************************
* Jin-min Lin
* Software Engineer
* VIA Technologies
* Phone  : 886-2-2185452 ext 363
* FAX    : 886-2-2185453
* E-Mail : min@via.com.tw
*********************************
From:	John Nels Fuller
Sent:	Saturday, November 09, 1996 9:59 AM
To:	'1394ohci-l@austin.ibm.com'; 'min@via.com.tw'
Subject:	RE: rcv bit in Control register

It is my understanding that rcvSelfID is independent of the other bits
because there is a separate mechanism for delivery of SelfID packets.
However, when rcvEnable is clear it is not possible to receive the other
PHY packets since they would be put into the GRU.

If I'm wrong, I'm sure someone will let us know.  Nonetheless, thanks
for bringing this up, we will make this more clear in future versions.

>----------
>From: 	Jimmy[SMTP:min@via.com.tw]
>Sent: 	Friday, November 08, 1996 7:11 PM
>To: 	1394ohci-l@austin.ibm.com
>Subject: 	rcv bit in Control register
>
>Hi, everyone :
>
>	There are 3 bits in Control register to control packet receiving. They
>are rcvEnable, rcvPhyPkt and rcvSelfID. If the rcvEnable is disabled,
>will the physical packet and the self identify packet be received ?
>
>	Should the OpenHCI controller put the physical packet to self identify
>buffer or put it to GRU ?
>
>*********************************
>* Jin-min Lin
>* Software Engineer
>* VIA Technologies
>* Phone  : 886-2-2185452 ext 363
>* FAX    : 886-2-2185453
>* E-Mail : min@via.com.tw
>*********************************
>
From:	John Nels Fuller
Sent:	Saturday, November 09, 1996 10:08 AM
To:	'1394OpenHCI'
Subject:	FW: DBDMA for GRU

Opps, forgot to include the reflector on this reply...

>----------
>From: 	John Nels Fuller
>Sent: 	Saturday, November 09, 1996 10:04 AM
>To: 	'Shu-Ming Liu'
>Subject: 	RE: DBDMA for GRU
>
>The GRU is intended to only work in Buffer-fill mode.  In this mode
>INPUT_MORE and INPUT_LAST are equivalent, incoming packets may have part of
>their data stored at the end of a buffer described by one INPUT command and
>the rest of their data stored at the begining of the buffer described by the
>next INPUT command.
>
>----------
>From: 	Shu-Ming Liu[SMTP:sis.com.tw@sis.com.tw]
>Sent: 	Friday, November 08, 1996 3:18 AM
>To: 	min@via.com.tw
>Cc: 	1394ohci-l@austin.ibm.com
>Subject: 	Re: DBDMA for GRU
>
>At 04:47 PM 11/8/96 +0800, you wrote:
>>Hi, everyone
>>
>>	I have some question for GRU.
>>
>>	According 6.4.1 of OpenHCI draft 0.75, "Data chaining across channel
>>commands is not supported." And the header should always be saved into
>>memory for GRU to inform the software what kind packet has been
>>received.
>>
>>	It seems that only OUTPUT_LAST and KEY_STREAM0 (packet-per-buffer with
>                           ^^^^^^^^^^^ -> should be INPUT_LAST
>>headers) can be supported for GRU to receive data. And its reqCount
>>field must larger than or equal to the maximum packet length + 5
>>quadlets.
>>
>>	Should OUTPUT_MORE be executed same as OUTPUT_LAST in GRU ? And should
>               ^^^^^^^^^^^ -> INPUT_MORE       ^^^^^^^^^^^ -> INPUT_LAST
>  
>  IMHO, I think only INPUT_LAST can be used in GRU. Spec. says "input packet
>defined by zero or more INPUT_MOREs followed by INPUT_LAST"
>
>>KEY_STREAM1, KEY_STREAM2 and KEY_STREAM3 be executed same as KEY_STREAM0
>>in GRU ? Or these command should be treated as a error condition ?
>
>  According to OHCI Draft 0.75 page 33, ".. only KEY_STREAM0 is implemented
>for asynchrounous receive...".
>
>>
>>Thanks
>>
>>*********************************
>>* Jin-min Lin
>>* Software Engineer
>>* VIA Technologies
>>* Phone  : 886-2-2185452 ext 363
>>* FAX    : 886-2-2185453
>>* E-Mail : min@via.com.tw
>>*********************************
>>
>>
>>
>***************************************************************
>*Shu-Ming Liu                                                 *
>*Software Engineer                                            *
>*Software Design Department                                   *
>*Silicon Integrated Systems Corp.                             *
>*Phone 886-35-774922 ext 4157                                 *
>*Fax   886-35-790651                                          *
>*mailto shuming@sis.com.tw                                     *
>*Address: No 16, Creation Rd 1,                               *
>*         Science-based Industrial Park,                      *
>*         Hsinchu, Taiwan                                     *
>***************************************************************
>
>
>
From:	John Nels Fuller
Sent:	Saturday, November 09, 1996 10:09 AM
To:	'1394ohci-l@austin.ibm.com'; 'cylin@sis.com.tw'
Cc:	'shuming@sis.com.tw'; 'cmlin@sis.com.tw'
Subject:	RE: STORE/LOAD_QUAD w/ KEY_STREAM/SYSTEM in DBDMA

Sorry that we haven't responded to your questions, but this is currently
under debate.  We will let you know as soon as we have figured it out.

>----------
>From: 	cylin@sis.com.tw[SMTP:cylin@sis.com.tw]
>Sent: 	Tuesday, October 29, 1996 12:42 AM
>To: 	1394ohci-l@austin.ibm.com
>Cc: 	shuming@sis.com.tw; cmlin@sis.com.tw
>Subject: 	STORE/LOAD_QUAD w/ KEY_STREAM/SYSTEM in DBDMA
>
>Hi, all:
>
>I have some questions about DBDMA. In OHCI0.6, KEY_STREAMn and 
>KEY_SYSTEM are supported for STORE_QUAD and LOAD_QUAD commands,
>
>1) In what occasion will the two commands w/ either of these two
>   keys be used?
>
>2) What should be done for this kind of commands?- Initiates
>   a PCI read/write cycle with the data and address given in the
>   command? This action does not make sense for LOAD_QUAD command
>   since the data obtained in the PCI read cycle will be written 
>   back later through a PCI write.
>
>Another question is about the STORE/LOAD_QUAD command when the
>key assigned is KEY_REGS- what address will be given in the address
>field? Address offset or KEY_REGS address (as given in Table 5-3)?
>
>Thanks for your help,
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Chien-Yuh Lin
>Silicon Intergrated Systems Corporation
>Tel: 886-3-5774922 x 4326
>Fax: 886-3-5778774
>Email: cylin@sis.com.tw
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Sunday, November 10, 1996 11:02 PM
To:	1394ohci-l@austin.ibm.com
Subject:	IR Configuration Register for IRDMA Channel A

Hi, all,
  
  I have a question about IR Configuration Register for IRDMA Channel A. 

  Since it can receive packets from multiple isochronous channels per cycle,
how shall we interprete the meaning of IR status bits s1 and s0. Are these
two status generating on any packet matching it ,or all packets should match
the condition? 

  Also I think the channel field can be removed. 

  Thanks in advance.
***************************************************************
*Shu-Ming Liu                                                 *
*Software Engineer                                            *
*Software Design Department                                   *
*Silicon Integrated Systems Corp.                             *
*Phone 886-35-774922 ext 4157                                 *
*Fax   886-35-790651                                          *
*mailto shuming@sis.com.tw                                     *
*Address: No 16, Creation Rd 1,                               *
*         Science-based Industrial Park,                      *
*         Hsinchu, Taiwan                                     *
***************************************************************

From:	wjshieh@sis.com.tw
Sent:	Tuesday, November 12, 1996 11:51 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw
Subject:	packet event codes for ATDMA

Hi, all:
 
  According to 1394 OpenHCI draft 0.75, Table 6-4 on page 44, 
two event codes (evt_short_packet and evt_long_packet) are added. 
The comments for these two event codes say that they are only 
used for received packets. But since Table 6-4 is for ATDMA which 
is used to transmit asynchronous packets, what is the meaning of 
evt_short_packet or evt_long_packet here?

Thanks for your help,

======================================
Whieh-Jen Shieh
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp. (SiS)
Phone  : 886-3-5774922 ext. 4314
Fax    : 886-3-5790651
E-mail : wjshieh@sis.com.tw
======================================

From:	Guy Bonneau [guy.bonneau@matrox.com]
Sent:	Wednesday, November 13, 1996 11:04 AM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

Subscribe

Please could you add my name to the mailing list of the
Open HCI reflector

Thanks

______________________________________________________________________

 Guy Bonneau,                         
 Senior Software Engineer,             Email : Guy.Bonneau@matrox.com
 Video Products Group                  voice : (514) 685-7230 X-2718
 Matrox Electronic Systems Ltd         fax   : (514) 685-7030 
                                       WWW   : http://www.matrox.com

 Head Office :                          US Mail :
 1055 St-Regis, Dorval, Qc              Trimex Building, 2330 Route 11
 CANADA   H9P 2T4                       Mooers N.Y. 12958-0219

In my most clearsighted moments not only do I not
think myself a nice man, but I know that I am a very 
nasty one. I can look at some of the things I have done 
with horror and loathing.

                              C.S. Lewis
______________________________________________________________________

From:	otejayad@central.fmi.fujitsu.com
Sent:	Wednesday, November 13, 1996 1:19 PM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

please add me to 1394 OHCI mailing list
From:	Jimmy [min@via.com.tw]
Sent:	Wednesday, November 13, 1996 10:16 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Question about ARDMA and interrupts

Hi, All



	The OpenHCI says that no general purpose status bits are allocated in
AR DMA channel. If the interrupt/wait/branch condition == 1 or 2 in
DBDMA command, should the DMA channel interrupt/wait/branch ?



	And if all DBDMA command sets interrupt to be always generated, is
asynchRX bit same with gruInt bit in IntEvent register ?



	According the P1394, physical register value returned by status
transfer. If the phyRegRcvd bit in IntEvent register is set, should the
phyInt always be set ?



Thanks



*********************************

* Jin-min Lin

* Software Engineer

* VIA Technologies

* Phone  : 886-2-2185452 ext 363

* FAX    : 886-2-2185453

* E-Mail : min@via.com.tw

*********************************
From:	daisy@sis.com.tw
Sent:	Wednesday, November 13, 1996 10:04 PM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Subject:	ATRetries OP register

Hi, everyone,

        I have a question for ATRetries OP register :

        In OHCI08 section 3.5, it says the AT retries register is used by Asyn
request DMA only, PRSU and DRSU are not retried, which is inconsistent with the
statement in Table 3-4, Table 6-1, and sDo Iection 6.3.3.

        Did I misunderstand the spec. ? Could anyone give a clear explanation
about this ? Thanks for your help.

 
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Wednesday, November 13, 1996 9:07 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Serial ROM image format

Hi, all,

  I have some question about 1394 add-in card expansion ROM.

  1. According to 1394 OHCI Draft 0.8, clause B.3 says: "If this ROM is
non-writeable and soldered to the card, it is also permitted that the serial
ROM image must be loaded into the 1394 OHC by hardware state machine...",
shall the address offset of this image in expansion ROM need to be
specified? By doing this, hardware can use the mechanism like GUID ROM
register interface to autoload the image.

  2. "....PCI expansion ROMs that provide BIOS, Open Firmware, etc. to boot
and configure the card." Since the PCI and 1394 OHCI are standards, shall
the BIOS and Open Firmware also be standards in booting and configuration phase?

  3. If I do not desire for lagacy DOS support, can the card be
configurating till the initialization stage of driver loading? If yes, and
if the bootbility is an option, shall the expansion ROM remain required?

  4. My last question is about Serial ROM. Except GUID, is there any
information need to be stored in Serial ROM? If yes, what's their storing map?
   
Thanks in advance.
***************************************************************
*Shu-Ming Liu                                                 *
*Software Engineer                                            *
*Software Design Department                                   *
*Silicon Integrated Systems Corp.                             *
*Phone 886-35-774922 ext 4157                                 *
*Fax   886-35-790651                                          *
*mailto shuming@sis.com.tw                                     *
*Address: No 16, Creation Rd 1,                               *
*         Science-based Industrial Park,                      *
*         Hsinchu, Taiwan                                     *
***************************************************************

From:	daisy@sis.com.tw
Sent:	Thursday, November 14, 1996 12:42 AM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Subject:	question about timeStamp

Hi, everyone,

        I have a question about timeStamp :

        In OHCI08 Table5-2, timeStamp, it says, when set to one, received
packets will be marked with a 16-bit value indicating the time the packet was
received. While in section 7, all timeStamp field are 20-bit long, which one is
correct ? 

Thanks,

Y.J. Chao
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	Jimmy [min@via.com.tw]
Sent:	Thursday, November 14, 1996 1:02 AM
To:	1394ohci-l@austin.ibm.com
Cc:	shuming@sis.com.tw; cmlin@sis.com.tw
Subject:	Re: STORE/LOAD_QUAD w/ KEY_STREAM/SYSTEM in DBDMA

Dream Ku wrote:
> 
> ----------
> > From: John Nels Fuller <jfuller@MICROSOFT.com>
> > To: '1394ohci-l@austin.ibm.com'; 'cylin@sis.com.tw'
> > Cc: 'shuming@sis.com.tw'; 'cmlin@sis.com.tw'
> > Subject: RE: STORE/LOAD_QUAD w/ KEY_STREAM/SYSTEM in DBDMA
> > Date: Sunday, November 10, 1996 2:09 AM
> >
> > Sorry that we haven't responded to your questions, but this is currently
> > under debate.  We will let you know as soon as we have figured it out.
> >
> > >----------
> > >From:        cylin@sis.com.tw[SMTP:cylin@sis.com.tw]
> > >Sent:        Tuesday, October 29, 1996 12:42 AM
> > >To:  1394ohci-l@austin.ibm.com
> > >Cc:  shuming@sis.com.tw; cmlin@sis.com.tw
> > >Subject:     STORE/LOAD_QUAD w/ KEY_STREAM/SYSTEM in DBDMA
> > >
> > >Hi, all:
> > >
> > >I have some questions about DBDMA. In OHCI0.6, KEY_STREAMn and
> > >KEY_SYSTEM are supported for STORE_QUAD and LOAD_QUAD commands,
> > >
> > >1) In what occasion will the two commands w/ either of these two
> > >   keys be used?
> > >
> > >2) What should be done for this kind of commands?- Initiates
> > >   a PCI read/write cycle with the data and address given in the
> > >   command? This action does not make sense for LOAD_QUAD command
> > >   since the data obtained in the PCI read cycle will be written
> > >   back later through a PCI write.
> > >
> > >Another question is about the STORE/LOAD_QUAD command when the
> > >key assigned is KEY_REGS- what address will be given in the address
> > >field? Address offset or KEY_REGS address (as given in Table 5-3)?
> > >
	I think that it should be KEY_REGS address in Table 5-3.

> > >Thanks for your help,
> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >Chien-Yuh Lin
> > >Silicon Intergrated Systems Corporation
> > >Tel: 886-3-5774922 x 4326
> > >Fax: 886-3-5778774
> > >Email: cylin@sis.com.tw
> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > >
*********************************
* Jin-min Lin
* Software Engineer
* VIA Technologies
* Phone  : 886-2-2185452 ext 363
* FAX    : 886-2-2185453
* E-Mail : min@via.com.tw
*********************************
From:	daisy@sis.com.tw
Sent:	Thursday, November 14, 1996 1:24 AM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Subject:	multiChanMode of IRDMA

Hi, everyone :

        I have a question about multiChanMode of IRDMA :

        Can an IRDMA in multi-channel mode be started or stopped ona specific
cycle or an incoming sync pattern as single-channel mode one ? 

        If no, does that mean a multi-channel mode IRDMA will ignore all field
of the IR configuration register ?

        If yes, I think one condition may occur, suppose we have 2 IRDMA
channels, IRDMA#a and IRDMA#b, 
*IRDMA#a is multi-channel mode, accept channel 3,4, started on cycle 8, stopped
 on cycle 20;

*IRDMA#b is single-channel mode, accept channel 4, started on cycle 2;

during cycle 2 to cycle 7, the packets of channel 4 will be handled by
IRDMA#b, from cycle8 to cycle 20, the channel 4 packets will be processed by
IRDMA#a, after that, they will be processed by IRDMA#b.

Can this condition occur ? Is my guess in the wrong? 
Thanks for your help,

Y.J. Chao
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	Jimmy [min@via.com.tw]
Sent:	Thursday, November 14, 1996 1:58 AM
To:	1394ohci-l@austin.ibm.com
Cc:	shuming@sis.com.tw
Subject:	Re: IR Configuration Register for IRDMA Channel A

> 
> ----------
> > From: Shu-Ming Liu <sis.com.tw@sis.com.tw>
> > To: 1394ohci-l@austin.ibm.com
> > Subject: IR Configuration Register for IRDMA Channel A
> > Date: Monday, November 11, 1996 3:02 PM
> >
> > Hi, all,
> >
> >   I have a question about IR Configuration Register for IRDMA Channel A.
> >
> >   Since it can receive packets from multiple isochronous channels per
> cycle,
> > how shall we interprete the meaning of IR status bits s1 and s0. Are
> these
> > two status generating on any packet matching it ,or all packets should
> match
> > the condition?

	About the bit s1, I think that it should be channel independent. It is
synchronization with cycle time. Cycle time of all channel should be
same. So, no problem with s1.

	About the bit s0, I think it should be generated on any packet matching
the eSync field. If it generate a interrupt, the software should parsing
which channel matching the eSync field.

> >
> >   Also I think the channel field can be removed.

	At last of 6.5.1 of OpenHCI 0.75, it says that "this DMA channel always
ignores the channel field of the IRDMA configuration register and uses
the ChannelMask registers instead."

> >
> >   Thanks in advance.
> > ***************************************************************
> > *Shu-Ming Liu                                                 *
> > *Software Engineer                                            *
> > *Software Design Department                                   *
> > *Silicon Integrated Systems Corp.                             *
> > *Phone 886-35-774922 ext 4157                                 *
> > *Fax   886-35-790651                                          *
> > *mailto shuming@sis.com.tw                                     *
> > *Address: No 16, Creation Rd 1,                               *
> > *         Science-based Industrial Park,                      *
> > *         Hsinchu, Taiwan                                     *
> > ***************************************************************
> >

*********************************
* Jin-min Lin
* Software Engineer
* VIA Technologies
* Phone  : 886-2-2185452 ext 363
* FAX    : 886-2-2185453
* E-Mail : min@via.com.tw
*********************************
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Thursday, November 14, 1996 1:40 AM
To:	1394ohci-l
Subject:	Today's Number

Hi,

    1-800-619-8522, pw=conan.

    10:30 Central Time.

    Best Regards,
    Lee
From:	cylin@sis.com.tw
Sent:	Thursday, November 14, 1996 7:37 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw; shuming@sis.com.tw
Subject:	evt_short/long_packet code

Hi,all:

I have some questions concerning evt_short/long_packet code in 
Table 6-2 in OHCI0.8: 
Where to use these two codes?- In the errCode of a received packet? 
Is it true that the encoding of the errCode of a received
packet is the one given in Table 6-2?

Thanks for you help,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	daisy@sis.com.tw
Sent:	Thursday, November 14, 1996 7:36 PM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Subject:	questions about errCode in receive packet format

Hi, everyone,

I have some questions about errCode in receive packet format,
in OHCI Drift 0.8, Table 7-4 says, errCode field holds the "acknowledge"
sent by the Link for this packet or an "error code" if this packet was not sent
successfully.

1). How to fill this 5-bit field while the acknowledge code is only 4-bit long?
2). What is the encode method of "error code" ?
3). Does the errCode has any relation to the packet event codes in Table 6-2 ?

Thanks for your help,

Y.J. Chao

          
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	Jimmy [min@via.com.tw]
Sent:	Thursday, November 14, 1996 10:14 PM
To:	1394ohci-l@austin.ibm.com
Subject:	flush bit in DBDMA control register

Hi, All

	I have a question about the flush bit in DBDMA control register. On
OpenHCI 0.8 page 41, it says that "a running DMA channel will finish the
reception of the packet currently being received".

	What means the "finish" ? Should the DBDMA discare the remains data of
this packet ? Should this command descriptor be completed, and start
next descriptor when next packet received ?

*********************************
* Jin-min Lin
* Software Engineer
* VIA Technologies
* Phone  : 886-2-2185452 ext 363
* FAX    : 886-2-2185453
* E-Mail : min@via.com.tw
*********************************
From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Friday, November 15, 1996 1:51 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; cylin@sis.com.tw; wjshieh@sis.com.tw
Subject:	Questions about OHCI0.8

Hi, all,

  Here I have some questions about OHCI0.8. I appreciate your patience to
read them and thank in advance if you want to answer.

  1. Shall the number of isochronous transmit channel be 64? If yes, since
isoTxArrayEnable and isoTxArrayUpdate are both register pair, they shoud be
defined in Table 2-3. And ITArraySize field should be modified to 6 bits.

  2. Page 20, Table3-10. Does the phyDMAEnable bit control the total funtion
of PRSU or just the funtion of physical memory accessing? Since PRSU will
handle three kinds of addresses automatically, one of them is Configuration
ROM which is mapped to main memory, I am confused about the definition of
physical memory and can not use this bit precisely. 

  3. Page 26, Table4-1. In what condition does phyInt generate? If it is
generated when phy requests an interrupt through a status transfer, I guess
only State Time-out is meanful(Table J-10 of P1394 Spec.). Am I right?

  4. Page 26, Table4-1,"phyRegRcvd: The 1394 Open HCI has received a PHY
register data byte which can be read from the GUID ROM register(optional)".
Does it say that both when rdDone of PHY control register be set and when
dataReady of GUID ROM register be set, the interrupt will generate?

  5. In what condition will S7..S0 be modified? Channel command will
generate i,b,r conditions after command completion, who else will use them?

  6. Page 33. Table5-6,"NAME: KEY_STREAM0, DESCRIPTION: Packet data or
LOAD/STORE location is in host memory. COMMANDS: all." In what condition
will load/store need to use key_stream0?

Thanks for your help.
***************************************************************
*Shu-Ming Liu                                                 *
*Software Engineer                                            *
*Software Design Department                                   *
*Silicon Integrated Systems Corp.                             *
*Phone 886-35-774922 ext 4157                                 *
*Fax   886-35-790651                                          *
*mailto shuming@sis.com.tw                                     *
*Address: No 16, Creation Rd 1,                               *
*         Science-based Industrial Park,                      *
*         Hsinchu, Taiwan                                     *
***************************************************************

From:	cylin@sis.com.tw
Sent:	Friday, November 15, 1996 4:16 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; shuming@sis.com.tw
Subject:	Header for OUTPUT_* w/ KEY_STREAM1/2

Hi, all:

I have a question about OUTPUT_* command with KEY_STREAM1 or
KEY_STREAM2 defined in OHCI0.8. That is, where to get the header information
to form the packet to transmit in the serial bus?
The spec. doesn't seem to point out a source for this.

Thanks in advnace for your help,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	Eric W. Anderson [ewa@apple.com]
Sent:	Friday, November 15, 1996 7:05 PM
To:	min@via.com.tw; 1394ohci-l@austin.ibm.com
Subject:	Re: flush bit in DBDMA control register

>Hi, All
>
>	I have a question about the flush bit in DBDMA control register. On
>OpenHCI 0.8 page 41, it says that "a running DMA channel will finish the
>reception of the packet currently being received".
>
>	What means the "finish" ? Should the DBDMA discare the remains data of
>this packet ? Should this command descriptor be completed, and start
>next descriptor when next packet received ?
>
>*********************************
>* Jin-min Lin
>* Software Engineer
>* VIA Technologies
>* Phone  : 886-2-2185452 ext 363
>* FAX    : 886-2-2185453
>* E-Mail : min@via.com.tw
>*********************************

In this context, "finish" means that the reception of the packet
completes normally.  Nothing happens differently because of the
flush, except for the status update as described.

In particular, if the DMA is processing an INPUT_MORE and the buffer
still has room for more packets, the flush does not cause the DMA to
skip to another descriptor.

If the flush causes a status update, but there is still more room,
there can be *another* status update on the same descriptor when
it finishes (if s == 0) or if it is flushed again.

[In OpenHCI 0.8 and forward the DMA is no longer known as "DBDMA",
though it is still very similar to DBDMA.]


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------



From:	daisy@sis.com.tw
Sent:	Sunday, November 17, 1996 10:19 PM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Subject:	Questions about IR packet format

Hi, everyone :

I have some questions about Isochronouns receive packet format, please give
me some suggestions, thanks.

In OHCI v0.8, there are two bits in DMA ChannelControl register, isochHeader and
timeStamp which will affect the format of the IR packet. isochHeader decides
whether the 4-byte packet header will precedes the packet payload, 
while timeStamp decides whether the time stamp will be included. 
Following is my questions :

1. Is it possible that driver want neither timeStamp nor packet header, ie.,
   isochHeader = '0' and timeStamp = '0' ? The examples shown in section 7.3
   do not include this case.

2. If isochHeader = '0', does the hardware have to strip the padding field 
   also ?
   Since in the previous version of OHCI(v0.4 ~ v0.6), key_stream1 resulted
   in stripping header and padding field and left data only, I'm not sure 
   if isochHeader = '0' will cause the padding field be stripped.

Hope my questions have been clearly described, and thanks for your reading.

Regards,

Y.J. Chao
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Sunday, November 17, 1996 9:21 PM
To:	min@via.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: Question about ARDMA and interrupts

At 02:15 PM 11/14/96 +0800, you wrote:
>Hi, All
>
>
>
>	The OpenHCI says that no general purpose status bits are allocated in
>AR DMA channel. If the interrupt/wait/branch condition == 1 or 2 in
>DBDMA command, should the DMA channel interrupt/wait/branch ?
>
  Only conditions 0 & 3 are permitted in GRU.
>
>
>	And if all DBDMA command sets interrupt to be always generated, is
>asynchRX bit same with gruInt bit in IntEvent register ?
  AsynchRX is generated when an AR DMA command is completed.
  GruInt may be generated during the execution phase of AR DMA command,
because GRU is intended to use buffer-fill mode.  
>
>
>
>	According the P1394, physical register value returned by status
>transfer. If the phyRegRcvd bit in IntEvent register is set, should the
>phyInt always be set ?
>
>
>
>Thanks
>
>
>
>*********************************
>
>* Jin-min Lin
>
>* Software Engineer
>
>* VIA Technologies
>
>* Phone  : 886-2-2185452 ext 363
>
>* FAX    : 886-2-2185453
>
>* E-Mail : min@via.com.tw
>
>*********************************
>
>
>
***************************************************************
*Shu-Ming Liu                                                 *
*Software Engineer                                            *
*Software Design Department                                   *
*Silicon Integrated Systems Corp.                             *
*Phone 886-35-774922 ext 4157                                 *
*Fax   886-35-790651                                          *
*mailto shuming@sis.com.tw                                     *
*Address: No 16, Creation Rd 1,                               *
*         Science-based Industrial Park,                      *
*         Hsinchu, Taiwan                                     *
***************************************************************

From:	Yehuda Peled (972-4-8296149) [PELED@HAIFASC3.HAIFA.IBM.COM]
Sent:	Tuesday, November 19, 1996 1:20 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Cycle master

We have a few question on cycle master operation.

1.The Cycle master transmits a Cycle start packet every 125 usec.
What does the cycle master do with cycle start packets that should have
been sent during a 1394 bus reset ?
There are 3 options:
1.Discard the indication.
2.Send the packet immediately after the 1394 bus reset.
3.Discard the indication after 80 usec (maximum jitter).

Option 1 is the easiest, but can cause to unnecessary cycle loss.

2.Cycle lost during bus reset.
During bus reset the Link controller should skip the lost cycles, and
fetch the data of the next cycle, to avoid lost of synchronization.
What should be the indication for cycle lost ?
Please note that the answer to this question is depend on the previous
question.

3.What is the procedure to turn off a device that is a cycle master
and selecting a new cycle master without losing any isoc cycles.

Any comment will be appreciate.

Thanks
 Yehuda

From:	cylin@sis.com.tw
Sent:	Wednesday, November 20, 1996 7:11 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; shuming@sis.com.tw; daisy@sis.com.tw
Subject:	DMA operation questions

Hi, all:

I have some questions about DMA operation of OHCI0.8:

1) The description for the dead bit of ChannelControl register in page
   29 said:
   "When a catastrophic hardware failure occurs, hardware sets the
   dead bit to one....The dead bit is not triggerred by any 1394 
   condition." But in Page 44, the meaning for s7 of the ATDMA status 
   bit said "error occured due to "bad" DMA data, such as incorrect 
   tCode. Should be looked at when the channel goes dead...." According
   to the desciprtion in page 44, dead bit needs to be
   set when bad DMA data like tCode error occurs, which is clearly not
   a hardware failure, the two statements conflict with each other.
   (By the way, what else will the bad DMA data be, except for tCode
   error?) 

2) In page 30, it stated that "Desciprtors that may have been 
   prefetched must not be modified while they execute.". Is it 
   correct to say that STOP command should not be included in any
   desciprtor block since it is very probably be modified (by
   replacing by a new command)?

3) In page 37, Table 5-12, for INPUT_MORE command, it said that "
   Any INPUT_MORE command must be followed by either another 
   INPUT_MORE command, an INPUT_LAST command, or (only in bufferFill 
   mode) a STOP command." However, in page 57, in the IR channel
   program example, the INPUT_MORE command is followed by a NOP.
   It seems to me NOP is o.k. too.

Thanks for your time and patient for reading this mail.
Now, here is my anwer to my last question - as nobody answer it,

>I have a question about OUTPUT_* command with KEY_STREAM1 or
>KEY_STREAM2 defined in OHCI0.8. That is, where to get the header
>information to form the packet to transmit in the serial bus?
>The spec. doesn't seem to point out a source for this.

The data of KEY_STREAM1/2 could be themself the header, or could
be part of the packet. Therefore, no problem.

Thanks a lot in advance if you would like to answer this mail.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	cylin@sis.com.tw
Sent:	Wednesday, November 20, 1996 5:59 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw
Subject:	Status update for skipped AT command

Hi, all,

Here is a question about skipped AT command:

In asynchronous transmission, if the OUTPUT_* command needs to be 
skipped because "enableAT" is not yet set, and if command.s = 0, 
then should the xferStatus and the timeStamp be updated for this 
command? If so, what should be the packet event code in xferStatus 
and the time in timeStamp?

I appreciate it if you would like to answer.



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	cylin@sis.com.tw
Sent:	Wednesday, November 20, 1996 6:48 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw; shchuang@sis.com.tw
Subject:	ITU status update

Hi, all,

Does ITU need to update the status? If so, what is the contents
of the status update? Thanks.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	Jimmy [min@via.com.tw]
Sent:	Thursday, November 21, 1996 10:40 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Packet format for isochronous transmit

Hi All,

	In OpenHCI chapter 0.8, there are packet formats for asynchronous
transmit/receive and isochronous receive. But there is not packet format
for isochronous transmit. Does isochronous packet transmit using the
P1394 packet format without any extra information ? If so, how can we
specify the speed for isochronous transmit ?

Thanks

*********************************
* Jin-min Lin
* Software Engineer
* VIA Technologies
* Phone  : 886-2-2185452 ext 363
* FAX    : 886-2-2185453
* E-Mail : min@via.com.tw
*********************************
From:	Jimmy [min@via.com.tw]
Sent:	Friday, November 22, 1996 1:05 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Compare & Swap CSR registers

Hi, All

	If the OpenHCI controller receives a packet that want to compare and
swap CSR registers (eg. BUS_MANAGER_ID), should the OpenHCI controller
execute this command and auto response ? Or, should it pass the packet
to software to use the CSR compare and swap registers to process it ?

Thanks

*********************************
* Jin-min Lin
* Software Engineer
* VIA Technologies
* Phone  : 886-2-2185452 ext 363
* FAX    : 886-2-2185453
* E-Mail : min@via.com.tw
*********************************
From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Friday, November 22, 1996 5:39 PM
To:	min@via.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: Compare & Swap CSR registers

At 05:05 PM 11/22/96 +0800, you wrote:
>Hi, All
>
>	If the OpenHCI controller receives a packet that want to compare and
>swap CSR registers (eg. BUS_MANAGER_ID), should the OpenHCI controller
>execute this command and auto response ? Or, should it pass the packet

Sure, they can be directly handled by PRQU. See OHCI0.8 Page 54.

>to software to use the CSR compare and swap registers to process it ?
>
>Thanks
>
>*********************************
>* Jin-min Lin
>* Software Engineer
>* VIA Technologies
>* Phone  : 886-2-2185452 ext 363
>* FAX    : 886-2-2185453
>* E-Mail : min@via.com.tw
>*********************************
>
>
>
***************************************************************
*Shu-Ming Liu                                                 *
*Software Engineer                                            *
*Software Design Department                                   *
*Silicon Integrated Systems Corp.                             *
*Phone 886-35-774922 ext 4157                                 *
*Fax   886-35-790651                                          *
*mailto shuming@sis.com.tw                                     *
*Address: No 16, Creation Rd 1,                               *
*         Science-based Industrial Park,                      *
*         Hsinchu, Taiwan                                     *
***************************************************************

From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Wednesday, November 27, 1996 6:13 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; cylin@sis.com.tw; daisy@sis.com.tw
Subject:	Z value encoding of DMA operation

Hi, all,

  Here I got some questions about Z value encodeing of DMA operation. 

  1. If we use a STORE_QUAD command to self-modify a program, can it (just a
SINGLE store command) form a descriptor block?
     If yes, after executing it, shall DMA engine stop or fetch the
following 4 quadlets?   

     So, the question will become: "the Z value encoding is just a
suggestion or a strict rule which driver need to follow?"

  2. If we use a STOP command at the end of progrem, after the STOP be
executed and driver change it to a command with unconditional branch, shall
driver refill the CommandPtr register? If we don't refill it, the Z value
can only be obtained in the 3rd field of the new command.

  3. If the STOP command will be modified later, can it be grouped a
descriptor block with other commands, or we shall left it along to another
descriptor block? 

Thanks in advance.  
***************************************************************
*Shu-Ming Liu                                                 *
*Software Engineer                                            *
*Software Design Department                                   *
*Silicon Integrated Systems Corp.                             *
*Phone 886-35-774922 ext 4157                                 *
*Fax   886-35-790651                                          *
*mailto shuming@sis.com.tw                                     *
*Address: No 16, Creation Rd 1,                               *
*         Science-based Industrial Park,                      *
*         Hsinchu, Taiwan                                     *
***************************************************************

From:	DavidW@bangate.compaq.com
Sent:	Monday, December 02, 1996 6:36 AM
To:	sis.com.tw@sis.com.tw; 1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; cylin@sis.com.tw; daisy@sis.com.tw
Subject:	re: Z value encoding of DMA operation

Responses embedded below.

David Wooten

Shu-Ming Liu <sis.com.tw@sis.com.tw> Wrote:
| 
| Hi, all,
| 
|   Here I got some questions about Z value encodeing of DMA operation. 
| 
|   1. If we use a STORE_QUAD command to self-modify a program, can it (just a
| SINGLE store command) form a descriptor block?

STORE_QUAD to self-modify a program is not supported.  In fact, the old 
version of STORE_QUAD is being removed from the specification.

|      If yes, after executing it, shall DMA engine stop or fetch the
| following 4 quadlets?   
| 
|      So, the question will become: "the Z value encoding is just a
| suggestion or a strict rule which driver need to follow?"

Z value is _strict_ rule for the driver.  If the Z value does not match (e.g. 
at the Zth descriptor there is no unconditional branch) the hardware is 
allowed, but not required, to go to the deal state becaus the descriptor list 
is not properly formatted.

| 
|   2. If we use a STOP command at the end of progrem, after the STOP be
| executed and driver change it to a command with unconditional branch, shall
| driver refill the CommandPtr register? If we don't refill it, the Z value
| can only be obtained in the 3rd field of the new command.

STOP will not be a part of OpenHCI in the next release because of problems 
such as this.

| 
|   3. If the STOP command will be modified later, can it be grouped a
| descriptor block with other commands, or we shall left it along to another
| descriptor block? 
| 
| Thanks in advance.  
| ***************************************************************
| *Shu-Ming Liu                                                 *
| *Software Engineer                                            *
| *Software Design Department                                   *
| *Silicon Integrated Systems Corp.                             *
| *Phone 886-35-774922 ext 4157                                 *
| *Fax   886-35-790651                                          *
| *mailto shuming@sis.com.tw                                     *
| *Address: No 16, Creation Rd 1,                               *
| *         Science-based Industrial Park,                      *
| *         Hsinchu, Taiwan                                     *
| ***************************************************************
| 
| 
From:	Jimmy [min@via.com.tw]
Sent:	Tuesday, October 01, 1996 2:40 AM
To:	Chia-Yu Tsai; Chuan-Hui_Huang; Dream Ku; Enoch_Kuo; Feng-Gi_Yang; Jordon_Huang; P1394 discuss group; Stephen Chen; Yu-Chung Huang
Subject:	P1394 OpenHCI seminar

Hi All,

	There will be a seminar about P1394 OpenHCI at DEC 10, 1996 when 2:00
pm room 105.

	Every one is welcome.

Jin-min Lin
From:	Patrick_Yu@el.nec.com
Sent:	Thursday, December 05, 1996 2:22 AM
To:	cytsai@via.com.tw; chuan@via.com.tw; dream@via.com.tw; enoch@via.com.tw; yfg@via.com.tw; jordon@via.com.tw; 1394ohci-l@austin.ibm.com; stephen@via.com.tw; huang@via.com.tw; min@via.com.tw
Subject:	Re: P1394 OpenHCI seminar

Jin-min,

Is this a special seminar sponsored by VIA and held at your company's office in 
Taiwan?  Please advise.

Thank you for the attention to this communications.

Yours sincerely,
W.S.P. Yu
ASIC Strategic Marketing
NEC Electronics Inc.

______________________________ Reply Separator _________________________________
Subject: P1394 OpenHCI seminar
Author:  min@via.com.tw at INTERNET
Date:    12/5/96 1:33 AM


Hi All,
     
 There will be a seminar about P1394 OpenHCI at DEC 10, 1996 when 2:00
pm room 105.
     
 Every one is welcome.
     
Jin-min Lin

From:	Jimmy [min@via.com.tw]
Sent:	Tuesday, October 01, 1996 5:54 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Mistyping the eMail address

Hi all:

	Sorry for missing include the OpenHCI discuss group email address. The
P1394 OpenHCI seminor is for VIA internal only.

Jin-min Lin
From:	Gene P Matter [Gene_P_Matter@ccm.fm.intel.com]
Sent:	Thursday, December 05, 1996 5:29 PM
To:	leew@austin.ibm.com; cytsai@via.com.tw; chuan@via.com.tw; dream@via.com.tw; enoch@via.com.tw; yfg@via.com.tw; jordon@via.com.tw; 1394ohci-l@austin.ibm.com; stephen@via.com.tw; huang@via.com.tw; min@via.com.tw
Subject:	Re[2]: P1394 OpenHCI seminar


Text item: 


Jin-Min,
Please forward remaining logistics on the site, agenda, 
logistics, (maps/directions) and attendance requested. 
If you can arrange a bridge for teleconf.
for remote sites this would be much appreciated.

Best rgds- 
Gene Matter
Sr Staff Engineer
Platform Architect on High Speed Serail Buses and IO 
Intel Corp
1900 Prairie City Rd  FM5-62
Folsom, Ca 95630

(916) 356-4597  FAX (916) 356-2081
Email: Gene P Matter@ccm.fm.intel.com


Jin-min,

Is this a special seminar sponsored by VIA and held at your company's
office in
Taiwan?  Please advise.

Thank you for the attention to this communications.

Yours sincerely,
W.S.P. Yu
ASIC Strategic Marketing
NEC Electronics Inc.

______________________________ Reply Separator ________________________________
_
Subject: P1394 OpenHCI seminar
Author:  min@via.com.tw at INTERNET
Date:    12/5/96 1:33 AM


Hi All,

 There will be a seminar about P1394 OpenHCI at DEC 10, 1996 when 2:00
pm room 105.

 Every one is welcome.

Jin-min Lin

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: Re: P1394 OpenHCI seminar
To: cytsai@via.com.tw, chuan@via.com.tw, dream@via.com.tw, enoch@via.com.tw,
        yfg@via.com.tw, jordon@via.com.tw, 1394ohci-l@austin.ibm.com,
        stephen@via.com.tw, huang@via.com.tw, min@via.com.tw
Message-Id: <9611058497.AA849785419@intermail.el.nec.com>
Date: Thu, 05 Dec 96 02:21:54 PST
Received: from ccMail by intermail.el.nec.com (SMTPLINK V2.11.01)
     id AA849785419; Thu, 05 Dec 96 02:21:54 PST
From: Patrick_Yu@el.nec.com
Received: from intermail.el.nec.com (intermail.el.nec.com [143.103.3.89]) by MIS
sentry.el.nec.com (8.7.1/8.7.1) with SMTP id DAA09956; Thu, 5 Dec 1996 03:28:20
-0800 (PST)
Received: from MISsentry.el.nec.com (missentry.el.nec.com [192.216.82.86]) by ne
tmail1.austin.ibm.com (8.6.12/8.6.11) with SMTP id FAA19854 for <1394ohci-l@aust
in.ibm.com>; Thu, 5 Dec 1996 05:32:27 -0600
Received: from netmail1.austin.ibm.com by marceau.fm.intel.com (8.8.4/10.0i); Th
u, 5 Dec 1996 11:43:24 GMT
Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by fm
mail.fm.intel.com (8.7.4/8.7.3) with ESMTP id DAA22470 for <gene_p_matter@ccm.fm
.intel.com>; Thu, 5 Dec 1996 03:41:35 -0800 (PST)
Return-Path: leew@austin.ibm.com
From:	Toni Tappan [toni@skipstone.com]
Sent:	Friday, December 06, 1996 6:12 PM
To:	1394ohci-l@austin.ibm.com; 1394-sig@1394ta.org
Subject:	OpenHCI- Register Now!

NOTE: AFTER DECEMBER 7TH(I'm giving everyone 2 more days, registration for the December 18th and 19th OpenHCI meeting at the San Jose Fairmont will change from the regular fee of $120 to $150. To avoid the late registration charge, please fill out the registration form on the TA web site and get it in to me, ASAP!

A PLEA ABOUT HOTELS: If you are coming from out of town, PLEASE
arrange for your accommodations to be at the Fairmont. In addition, PLEASE
make sure whoever does your hotel booking  with the Fairmont, mentions
that you are staying there for the 1394 OpenHCI or 1394 Trade Association
meeting.
The amount the TA will have to pay the Fairmont for use of the facilities for this meeting is based on the amount of rooms being booked by attendees.  If the rooms do not get booked, the TA will have to cover the charges amounting to thousands of dollars, out of its general fund to pay for these rooms.
The $119 per night price at the Fairmont is a great rate, and by
staying right there where the meeting takes place, you won't have the extra expense of a rental
car or parking fees.
Therefore,  if you're coming from out of town, PLEASE do your company's
ledger and the TA's ledger a favor and make sure your room reservation
is at the Fairmont.

One more note:
We will not be accepting credit cards yet, so please, bring your checkbook or cash for your registration fee if you have not previously paid in advance.

Thank You Very Much For Your Cooperation,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TONI TAPPAN
1394 TRADE ASSOCIATION ADMINISTRATOR
512-305-0203(VOICE)
512-305-0212(FAX)
toni@skipstone.com
1394 TRADE ASSOCIATION
C/O SKIPSTONE, INC.
3925 W. BRAKER LN., STE., 425
AUSTIN, TX  78759
SKIPSTONE, INC.
http://WWW.1394ta.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From:	cylin@sis.com.tw
Sent:	Monday, December 09, 1996 1:38 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw; shuming@sis.com.tw
Subject:	IR w/ timestamp packet format and more

Hi,all,

I have two questions about OHCI0.8:

1) In the packet format of IR with timestamp, the first quadlet
of the packet contains the timestamp (the time of the cycle start
packet of the current cycle), speed code and the errCode which
indicates whether the packet was received correctly. The errCode,
obviously, can be obtained only after the entire packet is 
received. This may require that the first quadlet be transferred
in a separate PCI cycle. This, however, causes a problem when the
buffer allocated by a DMA command has been filled to the last byte,
but the entired packet has not yet been received in the RF -
the errCode is unknown. The DMA command get stuck because the
first quadlet of the packet has not and can not be filled!
Does this implies that a RF capable of accepting an entire packet
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
is required? It seems to be more reasonable that the errCode is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
attached at the end of the packet.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

2) In page 29, OHCI0.8, the description of flush bit said "When the
flush bit is one, a running DMA channel will finish the reception of
                                             ^^^^^^ 
the packet curretly being received,... The flush bit will be cleared
before the final descriptor status is updated."
           ^^^^^
What does "finish the packet currently being received" mean?
What does "before the final descriptor status is updated"?
Do they have the same meanings as the old DBDMA?

Thanks for your time and answer (if any),

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	DavidW@bangate.compaq.com
Sent:	Monday, December 09, 1996 7:52 AM
To:	cylin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com; cmlin@sis.com.tw; daisy@sis.com.tw; shuming@sis.com.tw
Subject:	re: IR w/ timestamp packet format and more

Respopnses embedded below.

David Wooten

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi,all,
| 
| I have two questions about OHCI0.8:
| 
| 1) In the packet format of IR with timestamp, the first quadlet
| of the packet contains the timestamp (the time of the cycle start
| packet of the current cycle), speed code and the errCode which
| indicates whether the packet was received correctly. The errCode,
| obviously, can be obtained only after the entire packet is 
| received. This may require that the first quadlet be transferred
| in a separate PCI cycle. This, however, causes a problem when the
| buffer allocated by a DMA command has been filled to the last byte,
| but the entired packet has not yet been received in the RF -
| the errCode is unknown. The DMA command get stuck because the
| first quadlet of the packet has not and can not be filled!
| Does this implies that a RF capable of accepting an entire packet
|                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
| is required? It seems to be more reasonable that the errCode is
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
| attached at the end of the packet.
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Some of this was a cut and paste problem.  We needed the timeStamp at the 
beginning of the packet and we just copied from the footer.  The next release 
will show this more precisely.

| 
| 2) In page 29, OHCI0.8, the description of flush bit said "When the
| flush bit is one, a running DMA channel will finish the reception of
|                                              ^^^^^^ 
| the packet curretly being received,... The flush bit will be cleared
| before the final descriptor status is updated."
|            ^^^^^
| What does "finish the packet currently being received" mean?
| What does "before the final descriptor status is updated"?
| Do they have the same meanings as the old DBDMA?

This is changed in the next release.  We got rid of flush and pause and, 
hopefully, have a clearer description of the way things start and stop 
cleanly.

| 
| Thanks for your time and answer (if any),
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	Toni Tappan [toni@skipstone.com]
Sent:	Tuesday, December 10, 1996 11:19 AM
To:	1394-sig@1394ta.org; 1394ohci-l@austin.ibm.com
Subject:	Reception at the OHCI Mtg

Hi Everyone!

Texas Instruments will be holding a reception for the attendees of the OHCI
meeting next week. Details are as follows:

 DATE: Wednesday, December 18, 1996
 
 SITE: Regency Room I
       The Fairmont Hotel San Jose
       170 South Market Street
       San Jose, CA 95113
 
 TIME: 5:00 to 7:00 PM
 
This event is open to all attendees of the Open HCI Meeting, compliments of
Texas Instruments.

See you there!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Toni Tappan
1394 TA Administrator
512-305-0203(1394 Trade Association)
512-305-0212(Fax)
toni@skipstone.com
www.1394ta.org(TA Web Site)
1394 Trade Association
c/o Skipstone
3925 W. Braker Ln., Ste. 425
Austin, TX  78759
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	sakurai@prd.snec.nec.co.jp
Sent:	Wednesday, December 11, 1996 8:58 PM
To:	1394ohci-l@austin.ibm.com


 Hello!!

 I have a question about 1394OHCI rev0.8.

 Why are both of Buffer-fill mode and Buffer-per-packet mode supported 
 on receiveDMA specification ?
 
 I think that I am enough Buffer-per-packet mode only supported.
 Because DeviceDriver can easily treat packet of Buffer-per-packet mode.

 I think that Buffer-fill is not necessary.

 Thanks for your any comments.


 Toshimi Sakurai


From:	sakurai@prd.snec.nec.co.jp
Sent:	Wednesday, December 11, 1996 9:02 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Buffer-fill mode


 Hello!!

 I have a question about 1394OHCI rev0.8.

 Why are both of Buffer-fill mode and Buffer-per-packet mode supported 
 on receiveDMA specification ?
 
 I think that I am enough Buffer-per-packet mode only supported.
 Because DeviceDriver can easily treat packet of Buffer-per-packet mode.

 I think that Buffer-fill is not necessary.

 Thanks for your any comments.


 Toshimi Sakurai

From:	DavidW@bangate.compaq.com
Sent:	Thursday, December 12, 1996 7:03 AM
To:	sakurai@prd.snec.nec.co.jp
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Buffer-fill mode

Sakurai,

Packet/buffer (buffer/packet) mode is mostly sufficient for isochronous 
receive.  However, buffer-fill mode is required for asynchronous receive 
because the system software can't predict the sizes of the arriving packets.  
Buffer-fill mode a _much_ more efficient way of handling reception of 
asynchronous requests and responses.  Given that we have to do buffer-fill on 
receive for asynchronous DMA, we don't think that it is particularly costly to 
make that capability available for isochronous receive also.  Then, In 
allowing buffer-fill mode on isochronous receive we create the option of 
having a single DMA context receive for several channels which is something we 
support.

If you come to the Open HCI for 1394 presentation next week you can get a lot 
more information about this.

David

P.S.  Open HCI for 1394 is not for USB.

sakurai@prd.snec.nec.co.jp Wrote:
| 
| 
|  Hello!!
| 
|  I have a question about 1394OHCI rev0.8.
| 
|  Why are both of Buffer-fill mode and Buffer-per-packet mode supported 
|  on receiveDMA specification ?
|  
|  I think that I am enough Buffer-per-packet mode only supported.
|  Because DeviceDriver can easily treat packet of Buffer-per-packet mode.
| 
|  I think that Buffer-fill is not necessary.
| 
|  Thanks for your any comments.
| 
| 
|  Toshimi Sakurai
| 
| 
From:	sakurai@prd.snec.nec.co.jp
Sent:	Thursday, December 12, 1996 4:25 PM
To:	DavidW@bangate.compaq.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Buffer-fill mode

David,

thank you for an advice.

>Sakurai,
>
>Packet/buffer (buffer/packet) mode is mostly sufficient for isochronous 
>receive.  However, buffer-fill mode is required for asynchronous receive 
>because the system software can't predict the sizes of the arriving packets.  
>Buffer-fill mode a _much_ more efficient way of handling reception of 
>asynchronous requests and responses.  Given that we have to do buffer-fill on 
>receive for asynchronous DMA, we don't think that it is particularly costly to 
>make that capability available for isochronous receive also.  Then, In 
>allowing buffer-fill mode on isochronous receive we create the option of 
>having a single DMA context receive for several channels which is something we 
>support.

I understand it. I was wrong.


>If you come to the Open HCI for 1394 presentation next week you can get a lot 
>more information about this.
>

I don't go to 1394OHCI conference, but my business partner will go to conference.
I receive information from him.

From:	cylin@sis.com.tw
Sent:	Thursday, December 12, 1996 5:57 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw; shuming@sis.com.tw
Subject:	questions about DMA interrupt

Hi, all,

I have two questions about DMA interrupt:

1) In OHCI0.8 page 29, the description for dead bit stated that "When a
catastrophic hardware falure occurs, hardware sets the dead bit to one
...an interrupt is generated (if enabled in the intMask register)..."
Is this interrupt the DMA interrupt? If so, the description for the
DMA interrupt stated that "...This bit is conditionally set upon
completion of a XXX DMA command...", then for the case that the dead 
bit is set to one, but the interrupt is not selected by command.i, 
should the DMA interrupt be issued?

2) At the completion of a DMA command, if an interrupt is selected to 
be issued, is it issued before, after or at the same time the status
update is performed (if command.s is zero)? Will software reference
the status update upon detection of an interrupt? If so, then it seems
the interrupt issue needs to follow the status update (if any).

Thanks for your help,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	DavidW@bangate.compaq.com
Sent:	Friday, December 13, 1996 6:40 AM
To:	cylin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com; cmlin@sis.com.tw; daisy@sis.com.tw; shuming@sis.com.tw
Subject:	re: questions about DMA interrupt

See below.

David Wooten
Compaq Computer Corp.

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, all,
| 
| I have two questions about DMA interrupt:
| 
| 1) In OHCI0.8 page 29, the description for dead bit stated that "When a
| catastrophic hardware falure occurs, hardware sets the dead bit to one
| ....an interrupt is generated (if enabled in the intMask register)..."
| Is this interrupt the DMA interrupt? If so, the description for the
| DMA interrupt stated that "...This bit is conditionally set upon
| completion of a XXX DMA command...", then for the case that the dead 
| bit is set to one, but the interrupt is not selected by command.i, 
| should the DMA interrupt be issued?

When dead gets set for a context, the unrecoverableError interrupt event is 
generated.  The 'normal' interrupt event bit for the context is _not_  set 
regardless of the setting of the I field in the descriptor.

| 
| 2) At the completion of a DMA command, if an interrupt is selected to 
| be issued, is it issued before, after or at the same time the status
| update is performed (if command.s is zero)? Will software reference
| the status update upon detection of an interrupt? If so, then it seems
| the interrupt issue needs to follow the status update (if any).

You are correct, interrupt should be generated after the status update.

| 
| Thanks for your help,
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Friday, December 13, 1996 7:03 AM
To:	1394-sig; 1394ohci-l
Cc:	Jim Jardine
Subject:	Agenda for 1394 OpenHCI Mtg and .9 Specification

Greetings,

     We are fast approaching the 1394 OpenHCI conference 
at the Fairmont Hotel on 12/18-19.  Those attending the 
meeting will be added to the 1394ohci-l reflector following the
meeting.  We will be restricting our reflectors to conference 
attendees to keep the review process sane (some education
is needed on this stuff).  There will then be a month long review 
followed by a page turning workshop the end of January.   We 
will not close the 1.0 version of the specification until June, '96.
This will give us time to learn things from implementers and 
programmers thereby guaranteeing we have a solid specification 
and solution. 

    We have been fairly quiet on a public basis since the first 
conference.  This is because we have all been working on this
full time coming to a consensus on a solid, acceptable 1394
OpenHCI.  I am sure this silence has been disconcerting to 
some of you, but we have not wanted to hand out "half-baked"
stuff.  Now, in going from .9 to 1.0 level, we enter a phase where
the promoters and the adopters need to work together closely
to insure effective device drivers and devices (they should 
interoperate if we do this right - that's the objective).

    You will be surprised to see that all DMA is still DBDMA-like.
There have been numerous modifications to the DMA and 
there have been an abundance of rumors about what has 
gone on with the DMA.  I am pleased to say that the DMA 
structures in 1394 OpenHCI kept their DBDMA base, addressed
all the drawbacks encountered and were ultimately found 
pleasing by all the promoters (after many hours of stimulating
debate).  We are very pleased with the .9 specification and we
hope you will be too.  You will also notice that Intel has become 
a very active promoter of  the 1394 OpenHCI since the last 
conference. 
 
    The .9 level of the 1394 OpenHCI specification is available 
at 3:30 Central Daylight Time today (Fri) at:
 
ftp://www.austin.ibm.com/pub/chrptech/1394ohci/ohci090.pdf

  We will be bringing copies to the conference, but we'd
appreciate it if you'd print one before coming so you can 
familiarize yourselves and save a few trees.

Here's the agenda:

Wednesday (12/18)  Beginning at 8:30AM at the Fairmont, San Jose:

   OpenHCI Progress                                      L. Wilson           
(IBM)
   1394 Overview                                              (TBD)
   Synopsis of Changes Since Last Conf.    L. Wilson           (IBM)
   DMA Overview                                              D. Klashman     
(Sun)
   Registers/Interrupts                                     J. Bennett         
(Intel)
   Async Receive DMA                                    R. Puri                
(Apple)
   Async Transmit DMA                                   R. Baker            
(TI) 
   Isoch. Receive DMA                                    E. Anderson      
(Apple) 

Thursday (12/19) Beginning at 8:30AM at the Fairmont, San Jose:

   Isoch Transmit DMA                                     E. Anderson    (Apple)
   SelfID/Phys DMA                                          D. Budko          
(Intel)
   Implementation Considerations                  P. Teng             
(National/S3)
   Error Recovery/Byte Swapping                   D. Wooten        (Compaq)
   Software Considerations                              J. Fuller            
(Microsoft)
   BIOS Considerations                                    C. Stevens       
(Phoenix)

We look forward to seeing you all at the Fairmont Hotel in San Jose.

Best Regards,
Lee Wilson
1394 OpenHCI Chairman
From:	Toni Tappan [toni@skipstone.com]
Sent:	Saturday, December 14, 1996 7:26 AM
To:	1394-sig-sc@1394ta.org; 1394-wg@1394ta.org; 1394ohci-l@austin.ibm.com
Subject:	Urgent Registration Info

This request is directed to the SC members, WG Chairs, and Presenters of/at TA meetings.
I have noticed that for all TA meetings that registrations are not being submitted in advance by many in the above mentioned groups. I cannot stress the importance of every individual pre-registering.
The failure to pre-register for the meetings throws the numbers off for catering, space planning, etc. In addition, by not registering in advance, I cannot have badges ready for you at the door which slows down the registration process considerably.
I cannot be held responsible (and don't have the time)to try and determine which of you have not registered and submit the info for you.
Therefore, please don't assume that "I know you will be there" and will take care of it for you.
Please get your registrations submitted as soon as possible for the upcoming meetings, one of which is next week!

Thank You for Your Cooperation,


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TONI TAPPAN
1394 TRADE ASSOCIATION ADMINISTRATOR
512-305-0203(VOICE)
512-305-0212(FAX)
toni@skipstone.com
1394 TRADE ASSOCIATION
C/O SKIPSTONE, INC.
3925 W. BRAKER LN., STE., 425
AUSTIN, TX  78759
SKIPSTONE, INC.
http://WWW.1394ta.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From:	cmlin@sis.com.tw
Sent:	Sunday, December 15, 1996 5:21 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw
Subject:	The question about SIDU

Hi all,

I have a question about OHCI0.8:

  If a bus reset occurs during the previous self-ID receive period,
whether are the timestamp and generation counter in the first quadlet
of the self-ID buffer updated or not for the previous receive? and
whether is the bit of "selfIDError" in the Self ID Count register set
or not?

Thanks for your time and answer,


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chi-Ming Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4324
Fax: 886-3-5790651
Email: cmlin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From:	DavidW@bangate.compaq.com
Sent:	Monday, December 16, 1996 7:17 AM
To:	cmlin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: The question about SIDU

When a bus reset occurs, the selfID process starts over, from the beginning.  
This is not an error condition.  For each bus reset, the generation number 
increments.  This is how the software keeps track of what is in the selfID 
buffer.

David

cmlin@sis.com.tw Wrote:
| 
| Hi all,
| 
| I have a question about OHCI0.8:
| 
|   If a bus reset occurs during the previous self-ID receive period,
| whether are the timestamp and generation counter in the first quadlet
| of the self-ID buffer updated or not for the previous receive? and
| whether is the bit of "selfIDError" in the Self ID Count register set
| or not?
| 
| Thanks for your time and answer,
| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chi-Ming Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4324
| Fax: 886-3-5790651
| Email: cmlin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
| 
From:	sakurai@prd.snec.nec.co.jp
Sent:	Monday, December 16, 1996 5:49 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Speedcode of IT


 Hello!!

 I have a question about 1394OHCI rev0.9.

 How can I know the SPDcode of Isochonous Transmit ?

 Rev0.9 seid ITContextControl.SPD is NOT MEANINGFUL and IT Data Format don't
 have the SPDcode.

 I think that "ITContextControl.SPD is MEANINGFUL" is better. 


 Thanks for your any comments.

 Toshimi Sakurai

From:	sakurai@prd.snec.nec.co.jp
Sent:	Monday, December 16, 1996 8:01 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Retry protocols


 Hello!!

 I have a question about retry protocol in 1394OHCI rev0.9.

 LINK item on Page.6 seid "support for both the single and dual phase
 retry protocol for receive packets".
 
  
 How can I select single or dual phase retry protocol?

 I think 1394OHCI must define RETRY_PROTOCOL_MODE.

 But RETRY_PROTOCOL_MODE isn't defined in Rev0.9.


 Thanks for your any comments.

 Toshimi Sakurai

From:	ganesan@trinc.com
Sent:	Tuesday, December 17, 1996 10:50 AM
To:	1394ohci-l@austin.ibm.com
Cc:	ganesan@trinc.com
Subject:	clarification required regarding Link layer specification

Hi,
   There is one clarification is required regarding Link layer
specification and the Ohci registers.
    I want to know how the Link layer specification bits are
mapped onto the Ohci registers.If they are mapped,then let me
know about their offset addresses.If not,inform me about their
locality. 
   [In P1394,Draft8.0v2(page no:144)
         Example: LK_CONTROL.request
                  LK_CONTROL.confirmation]
Thanks
Bye
Ganesan.
From:	gnreddy [gnreddy@austin.ibm.com]
Sent:	Monday, December 23, 1996 2:31 PM
To:	1394ohci-l@austin.ibm.com
Subject:	IEEE 1394 : Your inputs

Hi,

This is Gopal Reddy, working for 'WhiteSpace' project. In this project,
we are Planning to look at the feasibility of IEEE1394 interface.
Do we have the spec with us ?
Please let me know, any other documents/books related to IEEE 1394.
Looking forward for your inputs...............

My VM ID: greddy@ausvm6

Regards
-- gopal
............................................................
Phone: (512) 838 5143 (Office)      (512) 832 5169 (Resi.)
Email: gnreddy@austin.ibm.com  
............................................................
From:	cmlin@sis.com.tw
Sent:	Tuesday, December 24, 1996 3:55 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw
Subject:	The questions about OHCI0.9

Hi all,

I have some questions about OHCI0.9:

1.  When the PCI_Global_ Swap Bit is set, the pure PCI system data,
     such as the PCI configuration registers and the expansion ROM,
     aren't affected while the data between PCI system and OHCI,
     such as the OP registers and the transfer data of DMA controller,
     must be byte-swapped and the corresponding byte-enable signals
     are also swapped.  Am I right?

2. The noByteSwapData bit only affects the byte arrangement when
    the data from/to hardware FIFOs.  The byte-enable signals aren't
    affected by the noByteSwap bit.  They are according to the current
    DMA buffer address.  Am I rignt?

3. It says in page 112 as " If the Host Controller has as many pending
    writes as it has reporting registers additional writes may not be
    posted.  Instead the Host Controller will need to return ack_pending
   and only return a complete indication when the write is actually
   done."  The complete indication is returned by hardware only when
   the Rx packet is a physical write request packet.  Otherwise it is 
   returned by the software via the Async response Tx DMA.  Am I
   right?

4. It says in page 82 as "There is a single following quadlet which is  
    the first word of the PHY packet.  The following check word has
    already been verified and is not included."  However,  the two
    words of the PHY packet are both included in Figure 8-16, PHY
    packet receive format.  Which is right?

Thanks for your time and answer,


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chi-Ming Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4324
Fax: 886-3-5790651
Email: cmlin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	nvn@comit.com
Sent:	Wednesday, December 25, 1996 12:18 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Host Bus Interface

Hi,
     Can I get a more detailed block diagram on
     Host Bus Interface block in fig1-1 (1394 Open HCI conceptual block diagram)
     given in 1394 OHCI Specification draft 0.9

Thanks
nvn

e-mail nvn@comit.com

From:	Shu-Ming Liu [sis.com.tw@sis.com.tw]
Sent:	Wednesday, December 25, 1996 6:41 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; cylin@sis.com.tw; daisy@sis.com.tw
Subject:	Wait Mechanism for IRDMA (OHCI 0.9)

Hi, all,

  I have a question about wait mechamism for IRDMA.

  Page 95, "w bit: Wait control. Valid values are 2'b11 to wait a sync
and/or tag field which matches those specified in the context's
IRContextMatch register."

  Page 102, "syncCompareEnable: If set, this indicates that the sync field
of this register has a valid comparison value. Packets for the specified
channel number with a matching sync value will be received into the context
buffers."

  Page 102, "At least one tag bit must be set to 1, otherwise no received
packets will match and the context will, in effect, wait forever."

  My question is: From page 102, it seems the wait mechanism has been
implemented by ContextMatch register. If that's true, why shall we use
another wait bit to control tag/sync. Does that mean only when
ContextControl.wait==1, the setting in ContextMatch will be used?

  Thanks for your answers in advance.
***************************************************************
*Shu-Ming Liu                                                 *
*Software Engineer                                            *
*Software Design Department                                   *
*Silicon Integrated Systems Corp.                             *
*Phone 886-35-774922 ext 4157                                 *
*Fax   886-35-790651                                          *
*mailto shuming@sis.com.tw                                    *
*Address: No 16, Creation Rd 1,                               *
*         Science-based Industrial Park,                      *
*         Hsinchu, Taiwan                                     *
***************************************************************

From:	cylin@sis.com.tw
Sent:	Monday, December 23, 1996 9:24 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw; shuming@sis.com.tw
Subject:	DMA questions in OHCI0.9

Hi, all:

I have a few questions about DMA in OHCI0.9:

1) For AT, software used to provide the branch address for retry.
But now the command.branchAddress field always indicates the branch
address for the next descriptor block, thus next packet. Does this
imply that hardware needs to handle retry branch back itself?

2) For AT, during bus reset, AT will end the current data
transmission and then clears contextControl.active. Software 
will not clear IntEvent.busReset until both AT contexts clear
the contextControl.active bit. Will software clear 
contextControl.run before IntEvent.busReset is cleared? If not,
problem may arise after AT clears active. At that time, because
dead is not set and run is set, AT controller may try to fetch
the next descriptor block w/ an invalid commandPtr.

3) About CommandPtr, on page 17, it is stated that "If read after
ContextControl.run has been set, then CommandPTR.descriptorAddress
will contain the address of the next descriptor that will be 
accessed..." However, for AT retry and AR/IR back-out, the actual
next descrptor to be accessed cannot be determined until the 
command completion. Will this cause any problem to software?

Thanks for your help,



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	Patrick_Yu@el.nec.com
Sent:	Thursday, December 26, 1996 3:51 PM
To:	1394ohci-l@austin.ibm.com; nvn@comit.com
Subject:	Re: Host Bus Interface

N.V.,

I believe that the Host Bus Interface is kind of neutral as it has been defined.
So, it can be an internal bus in a highly integrated silicon or an external 
interface in a standalone application.   Nevertheless, the Host Bus Interface 
likely to be adopted by the silicon vendors in case of standalone application 
will be PCI-32bit @ 33MHz.  Indeed, an implementation specific example is 
described in the Appendix.

Just my two cents worth of opinion.  Thanks.

Yours sincerely,
W.S.P. Yu
NEC Electronics Inc.

______________________________ Reply Separator _________________________________
Subject: Host Bus Interface
Author:  nvn@comit.com (N V Narayanan) at INTERNET
Date:    12/25/96 12:24 PM


Hi,
     Can I get a more detailed block diagram on
     Host Bus Interface block in fig1-1 (1394 Open HCI conceptual block diagram) 
     given in 1394 OHCI Specification draft 0.9
     
Thanks
nvn
     
e-mail nvn@comit.com
     

From:	cmlin@sis.com.tw
Sent:	Friday, December 27, 1996 12:21 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw
Subject:	Questions about OHCI0.9

Hi all,

I have questions about OHCI0.9:

1. In page 20, OHCI0.9, it says "One simplification would be to place
    asynchronous requests into a first FIFO and then send all other
    transaction types (except for physical reads) through a second."  
    My question is in which FIFO  the physical reads transaction  is 
    placed.

2. In page 20, OHCI0.9, it says "After each request, other than a 
    physical write request, quadlet is placed in the FIFO the link
    side decrements the counter."  Whether is the physical read
    request also excluded?

3. Should the field of "reqCount" in the INPUT_MORE descriptor of
    Asynchronous Receive DMA be a multiple of quadlet?  It is convenient
    for the hardware design because the field of "dataAddress" is aligned on
    a quadlet boundary and the size of packet received by this DMA is also
    a multiple of quadlet. 

Thanks for your time and answer,


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chi-Ming Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4324
Fax: 886-3-5790651
Email: cmlin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	DavidW@bangate.compaq.com
Sent:	Friday, December 27, 1996 8:36 AM
To:	cmlin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: The questions about OHCI0.9

See below.

David Wooten

cmlin@sis.com.tw Wrote:
| 
| Hi all,
| 
| I have some questions about OHCI0.9:
| 
| 1.  When the PCI_Global_ Swap Bit is set, the pure PCI system data,
|      such as the PCI configuration registers and the expansion ROM,
|      aren't affected while the data between PCI system and OHCI,
|      such as the OP registers and the transfer data of DMA controller,
|      must be byte-swapped and the corresponding byte-enable signals
|      are also swapped.  Am I right?

You are correct.

| 
| 2. The noByteSwapData bit only affects the byte arrangement when
|     the data from/to hardware FIFOs.  The byte-enable signals aren't
|     affected by the noByteSwap bit.  They are according to the current
|     DMA buffer address.  Am I rignt?

Mostly you are right.  There is the strange case of having the noByteSwapData 
set on PCI an only having a couple of bytes of data.  The data is loaded left 
to right when noByteSwapData is set.  This means that the 0th byte in a 
quadlet is on the left.  SO if the address is quadlet aligned and there is 
only a single byte, it would be stored at PCI byte number 3 and not 0.  What 
one needs to do is to have the byte enable bits "follow" the storage of bytes 
within the quadlet according to the settings of the noByteSwapData bit.

| 
| 3. It says in page 112 as " If the Host Controller has as many pending
|     writes as it has reporting registers additional writes may not be
|     posted.  Instead the Host Controller will need to return ack_pending
|    and only return a complete indication when the write is actually
|    done."  The complete indication is returned by hardware only when
|    the Rx packet is a physical write request packet.  Otherwise it is 
|    returned by the software via the Async response Tx DMA.  Am I
|    right?

Correct.

| 
| 4. It says in page 82 as "There is a single following quadlet which is  
|     the first word of the PHY packet.  The following check word has
|     already been verified and is not included."  However,  the two
|     words of the PHY packet are both included in Figure 8-16, PHY
|     packet receive format.  Which is right?

The drawing is correct.  The second quadlet is included in the data buffer and 
is not checked by the link layer.  Any packet that is two quadlets long and 
that fails the CRC check will be assumed to be a PHY packet.  Software must 
insure that the second quadlet is the logical inverse of the first quadlet in 
order to verify that it is a PHY packet (the PHY does its checking the other 
way around.)

| 
| Thanks for your time and answer,
| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chi-Ming Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4324
| Fax: 886-3-5790651
| Email: cmlin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, December 27, 1996 8:43 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Host Bus Interface

A 'standard' block diagram is not available from the OpenHCI promoters.  
Implementation of this portion of the interface is dependent on the host bus 
to which the OHCI is connected.  That means that there is no 'standard'.  
Implementation of this portion of the interface is also considered to be 
vendor dependent.  You may be able to arrange to get a more detailed block 
diagram from someone who has done the implementation for a bus in which you 
are interested but it is not part of the OpenHCI deliverables.

David Wooten

nvn@comit.com (N V Narayanan) Wrote:
| 
| Hi,
|      Can I get a more detailed block diagram on
|      Host Bus Interface block in fig1-1 (1394 Open HCI conceptual block 
diagram)
|      given in 1394 OHCI Specification draft 0.9
| 
| Thanks
| nvn
| 
| e-mail nvn@comit.com
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, December 27, 1996 9:01 AM
To:	sis.com.tw@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Wait Mechanism for IRDMA (OHCI 0.9)

The syncCompareEnable bit might be redundant and we are considering taking it 
out.

Let me try to explain what is supposed to happen and I hope Eric Anderson of 
Apple will correct me if I get it wrong.

The tag bits act as a filter on _all_ packets for the context.  If the 
received packet has a tag value that does not correspond to the settings of 
the tag bits in the IRContextMatch register, the packet will be ignored (_not_ 
be placed in the input buffer.)

The syncCompareEnable only has meaning for a descriptor block that has wait 
set in the first descriptor.  When wait is set, the HC will discard all 
packets that don't match the tag field and have a sycn field that matches the 
setting of IRContextMatch.sync.  When a packet does match, the packet is 
received and the descriptor block containing the wait gets used causing the HC 
to advance to the next descriptor block (one that probably does not contain a 
wait.)

So far, we can only figure out how wait works in packet/buffer mode.  We don't 
yet have a useful definition for this function in buffer-fill mode.

I hope this helps.

Regards,

David Wooten

Shu-Ming Liu <sis.com.tw@sis.com.tw> Wrote:
| 
| Hi, all,
| 
|   I have a question about wait mechamism for IRDMA.
| 
|   Page 95, "w bit: Wait control. Valid values are 2'b11 to wait a sync
| and/or tag field which matches those specified in the context's
| IRContextMatch register."
| 
|   Page 102, "syncCompareEnable: If set, this indicates that the sync field
| of this register has a valid comparison value. Packets for the specified
| channel number with a matching sync value will be received into the context
| buffers."
| 
|   Page 102, "At least one tag bit must be set to 1, otherwise no received
| packets will match and the context will, in effect, wait forever."
| 
|   My question is: From page 102, it seems the wait mechanism has been
| implemented by ContextMatch register. If that's true, why shall we use
| another wait bit to control tag/sync. Does that mean only when
| ContextControl.wait==1, the setting in ContextMatch will be used?
| 
|   Thanks for your answers in advance.
| ***************************************************************
| *Shu-Ming Liu                                                 *
| *Software Engineer                                            *
| *Software Design Department                                   *
| *Silicon Integrated Systems Corp.                             *
| *Phone 886-35-774922 ext 4157                                 *
| *Fax   886-35-790651                                          *
| *mailto shuming@sis.com.tw                                    *
| *Address: No 16, Creation Rd 1,                               *
| *         Science-based Industrial Park,                      *
| *         Hsinchu, Taiwan                                     *
| ***************************************************************
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, December 27, 1996 9:18 AM
To:	cylin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: DMA questions in OHCI0.9

See below.

David Wooten

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, all:
| 
| I have a few questions about DMA in OHCI0.9:
| 
| 1) For AT, software used to provide the branch address for retry.
| But now the command.branchAddress field always indicates the branch
| address for the next descriptor block, thus next packet. Does this
| imply that hardware needs to handle retry branch back itself?

Yes.  Hardware will automatically do retires (for busy only) up to the limit 
specified in the ATRetries register.

| 
| 2) For AT, during bus reset, AT will end the current data
| transmission and then clears contextControl.active. Software 
| will not clear IntEvent.busReset until both AT contexts clear
| the contextControl.active bit. Will software clear 
| contextControl.run before IntEvent.busReset is cleared? If not,
| problem may arise after AT clears active. At that time, because
| dead is not set and run is set, AT controller may try to fetch
| the next descriptor block w/ an invalid commandPtr.

I think this is something that fell through the cracks as we tried to 'clean 
up' the spec.  There used to be a bit that was cleared to disable AT and this 
was cleared on a 1394 bus reset.  We got rid of it because we had the 
individual run bits which did the equivalent things.  However, we need to 
change the wording of the run descriptor in the AT context so that it 
indicates that both AT contexts (request and response) have run turned off 
when a 1394 bus reset is received.

Thanks for catching this.

| 
| 3) About CommandPtr, on page 17, it is stated that "If read after
| ContextControl.run has been set, then CommandPTR.descriptorAddress
| will contain the address of the next descriptor that will be 
| accessed..." However, for AT retry and AR/IR back-out, the actual
| next descrptor to be accessed cannot be determined until the 
| command completion. Will this cause any problem to software?

The paragraph you quote starts with the admonition:

 "This register [CommandPtr] may be read when ContextControl.active is 0. If 
read at any other time, the register value is undefined."

In the case you are concerned about, active is 1 so if SW reads CommandPtr, 
the value is undefined.

| 
| Thanks for your help,
| 
| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, December 27, 1996 9:34 AM
To:	cmlin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Questions about OHCI0.9

See below.

David Wooten

cmlin@sis.com.tw Wrote:
| 
| Hi all,
| 
| I have questions about OHCI0.9:
| 
| 1. In page 20, OHCI0.9, it says "One simplification would be to place
|     asynchronous requests into a first FIFO and then send all other
|     transaction types (except for physical reads) through a second."  
|     My question is in which FIFO  the physical reads transaction  is 
|     placed.

We have tried to avoid detailed discussions about physical read requests (read 
requests that access the first 4GB and get through the filters.)  This is 
because the implementation of read requests expected to be highly variable.  
When the HC is processing physical read requests, it is acting as a bridge and 
not a controller.  In its role as a bridge, there is no part of the interface 
that is controlled by SW.  Since SW doesn't need to interact with the physical 
read requests, we don't specify its implementation.  We think that physical 
read requests will be handled by separate hardware (seperate from all the 
other input FIFOs) and may or may not have a FIFO of its own (depends on host 
bus latency and number of read requests that need to be queued at a time.)

| 
| 2. In page 20, OHCI0.9, it says "After each request, other than a 
|     physical write request, quadlet is placed in the FIFO the link
|     side decrements the counter."  Whether is the physical read
|     request also excluded?

I'm not sure I understand the question.  A read request that is to low memory 
but that is not allowed because of the PhysicalRequestFilter gets thrown into 
the AR request buffer and is not considered to be a physical read request. So, 
a read is not a physical read unless it is handled by the physical read 
request/response unit.

So, read requests that will end up in the AR request buffer will cause the 
count to decriment.

| 
| 3. Should the field of "reqCount" in the INPUT_MORE descriptor of
|     Asynchronous Receive DMA be a multiple of quadlet?  It is convenient
|     for the hardware design because the field of "dataAddress" is aligned on
|     a quadlet boundary and the size of packet received by this DMA is also
|     a multiple of quadlet. 

Yes, the reqCount for AR (both request and response) should always indicate a 
quadlet and we should make that clear in the spec.

| 
| Thanks for your time and answer,
| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chi-Ming Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4324
| Fax: 886-3-5790651
| Email: cmlin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	Eric W. Anderson [ewa@apple.com]
Sent:	Friday, December 27, 1996 10:50 AM
To:	1394ohci-l@austin.ibm.com
Cc:	sis.com.tw@sis.com.tw
Subject:	re: Wait Mechanism for IRDMA (OHCI 0.9)

I believe David's explanation is correct.  Here is my own explanation,
from a slightly different direction.

There are a total of four controls for selecting packets received by
the IRDMA.  These controls act in a sort-of hierarchical fashion:

  1. The context is started on a specific cycle [optional]
  2. Once started, the context waits for a specific sync [optional]
  3. The context examines all packets for one (or more) channels
  4. Packets matching the selected tag bits are received

From a software point of view, a context would be set up in reverse
order of the above:

  4. Set the desired tag bits in contextMatch.  Set all four bits if
     you don't care about tags or don't know what tag to use.

  3. Set the channel number in contextMatch (or set multiChanMode in
     the ContextControl register and also set the IRMultiChanMask
     registers).

  2. If wait-for-sync is desired:
        2a. Fill in the desired sync in contextMatch, and set wait=3
            in the first descriptor of the IRDMA context program.
     Otherwise:
        2b. Set wait=0 in the first descriptor of the context program.

  1. If start-on-cycle is desired:
        1a. Fill in the desired start cycle in contextMatch, and set
            the cycleMatchEnable bit in contextControl.  Then set the
            run bit in contextControl.
     Otherwise:
        1b. Clear cycleMatchEnable and set run in contextControl.

In these steps, the syncCompareEnable bit was never used.  (Setting
wait=3 activated the sync-wait function).  I believe we agreed that
this bit can be removed.

Table 10-1 on Page 95 of OHCI 0.9 should be changed to remove the
mention of "tag" in the description of "w".  Waiting for a tag match
is not useful, because the tag filter function does the same thing.
I believe we agreed that this item should also mention that w=3 is
only allowed for the very first descriptor in a context program.

I believe that if wait is allowed only at the start of a program,
then it will work for both bufferFill and packet-per-buffer modes.
If we make wait a little more powerful, and allow it in a running
program, then I agree with David that it is only clearly useful
for packet-per-buffer mode.

Using wait in a running program could be useful for automatically
regaining sync when a packet is lost.  However, this would be done
by skipping one "sync frame" worth of packets (possibly a lot), so
in general I expect software would be able to do a better recovery
job by itself.

With or without the ability to wait on sync in a running program,
software can perform the re-sync itself by examining packet headers.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------

>The syncCompareEnable bit might be redundant and we are considering
>taking it out.
>
>Let me try to explain what is supposed to happen and I hope Eric
>Anderson of Apple will correct me if I get it wrong.
>
>The tag bits act as a filter on _all_ packets for the context.  If the 
>received packet has a tag value that does not correspond to the settings
>of the tag bits in the IRContextMatch register, the packet will be
>ignored (_not_ be placed in the input buffer.)
>
>The syncCompareEnable only has meaning for a descriptor block that has
wait 
>set in the first descriptor.  When wait is set, the HC will discard all 
>packets that don't match the tag field and have a sycn field that matches
>the setting of IRContextMatch.sync.  When a packet does match, the packet
>is received and the descriptor block containing the wait gets used causing
>the HC to advance to the next descriptor block (one that probably does not
>contain a wait.)
>
>So far, we can only figure out how wait works in packet/buffer mode.  We
>don't yet have a useful definition for this function in buffer-fill mode.
>
>I hope this helps.
>
>Regards,
>
>David Wooten
>
>Shu-Ming Liu <sis.com.tw@sis.com.tw> Wrote:
>| 
>| Hi, all,
>| 
>|   I have a question about wait mechamism for IRDMA.
>| 
>|   Page 95, "w bit: Wait control. Valid values are 2'b11 to wait a sync
>| and/or tag field which matches those specified in the context's
>| IRContextMatch register."
>| 
>|   Page 102, "syncCompareEnable: If set, this indicates that the sync
field
>| of this register has a valid comparison value. Packets for the specified
>| channel number with a matching sync value will be received into the
>| context buffers."
>| 
>|   Page 102, "At least one tag bit must be set to 1, otherwise no
received
>| packets will match and the context will, in effect, wait forever."
>| 
>|   My question is: From page 102, it seems the wait mechanism has been
>| implemented by ContextMatch register. If that's true, why shall we use
>| another wait bit to control tag/sync. Does that mean only when
>| ContextControl.wait==1, the setting in ContextMatch will be used?
>| 
>|   Thanks for your answers in advance.
>| ***************************************************************
>| *Shu-Ming Liu                                                 *
>| *Software Engineer                                            *
>| *Software Design Department                                   *
>| *Silicon Integrated Systems Corp.                             *
>| *Phone 886-35-774922 ext 4157                                 *
>| *Fax   886-35-790651                                          *
>| *mailto shuming@sis.com.tw                                    *
>| *Address: No 16, Creation Rd 1,                               *
>| *         Science-based Industrial Park,                      *
>| *         Hsinchu, Taiwan                                     *
>| ***************************************************************



From:	John Nels Fuller
Sent:	Friday, December 27, 1996 7:26 PM
To:	'cylin@sis.com.tw'; 'DavidW@bangate.compaq.com'
Cc:	'1394ohci-l@austin.ibm.com'
Subject:	RE: DMA questions in OHCI0.9

More about item 2:  Although it didn't make it into 0.9 we did agree
that after a bus reset s/w would clear both AT context run bits and wait
for both active bits to be cleared by h/w before resetting the interrupt
condition.  S/W might do this by clearing the run bits on the bus reset
interrupt and then clearing the bus reset interrupt later when the
self-id complete interrupt happens (assume appropriate intMask
manipulations).

>----------
>From: 	DavidW@bangate.compaq.com[SMTP:DavidW@bangate.compaq.com]
>Sent: 	Friday, December 27, 1996 9:18 AM
>To: 	cylin@sis.com.tw
>Cc: 	1394ohci-l@austin.ibm.com
>Subject: 	re: DMA questions in OHCI0.9
>
>See below.
>
>David Wooten
>
>cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
>| 
>| Hi, all:
>| 
>| I have a few questions about DMA in OHCI0.9:
>| 
>| 1) For AT, software used to provide the branch address for retry.
>| But now the command.branchAddress field always indicates the branch
>| address for the next descriptor block, thus next packet. Does this
>| imply that hardware needs to handle retry branch back itself?
>
>Yes.  Hardware will automatically do retires (for busy only) up to the limit 
>specified in the ATRetries register.
>
>| 
>| 2) For AT, during bus reset, AT will end the current data
>| transmission and then clears contextControl.active. Software 
>| will not clear IntEvent.busReset until both AT contexts clear
>| the contextControl.active bit. Will software clear 
>| contextControl.run before IntEvent.busReset is cleared? If not,
>| problem may arise after AT clears active. At that time, because
>| dead is not set and run is set, AT controller may try to fetch
>| the next descriptor block w/ an invalid commandPtr.
>
>I think this is something that fell through the cracks as we tried to 'clean 
>up' the spec.  There used to be a bit that was cleared to disable AT and this
>was cleared on a 1394 bus reset.  We got rid of it because we had the 
>individual run bits which did the equivalent things.  However, we need to 
>change the wording of the run descriptor in the AT context so that it 
>indicates that both AT contexts (request and response) have run turned off 
>when a 1394 bus reset is received.
>
>Thanks for catching this.
>
>| 
>| 3) About CommandPtr, on page 17, it is stated that "If read after
>| ContextControl.run has been set, then CommandPTR.descriptorAddress
>| will contain the address of the next descriptor that will be 
>| accessed..." However, for AT retry and AR/IR back-out, the actual
>| next descrptor to be accessed cannot be determined until the 
>| command completion. Will this cause any problem to software?
>
>The paragraph you quote starts with the admonition:
>
> "This register [CommandPtr] may be read when ContextControl.active is 0. If 
>read at any other time, the register value is undefined."
>
>In the case you are concerned about, active is 1 so if SW reads CommandPtr, 
>the value is undefined.
>
>| 
>| Thanks for your help,
>| 
>| 
>| 
>| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>| Chien-Yuh Lin
>| Design Engineer
>| Basic Technology Group
>| Silicon Intergrated Systems Corp.
>| Tel: 886-3-5774922 x 4326
>| Fax: 886-3-5778774
>| Email: cylin@sis.com.tw
>| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>| 
>| 
>
From:	cylin@sis.com.tw
Sent:	Monday, December 30, 1996 1:47 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw; shuming@sis.com.tw
Subject:	Error handling in OHCI0.9

Hi, all:

I have two questions about DMA error handling in OHCI0.9:

1) For a Rx DMA, there are three places that keep the xferStatus, i.e.,
the one in the ContextControl register in the chip(1), the one in the
descriptor list(2) and the one in the data buffer(3) in system.
For buffeFill-mode Rx DMA,
When a data write error occurs, ContextControl.dead will be set, 
status will not be updated for the descriptor, therefore,
(1) will be inconsistent with (2) and (3).
-- for packet/buffer mode, dead will not be set, (1)(2)(3) will be
-- consistent.
When a descriptor read error occurs, ContextControl.dead will be set, 
(1) will probably be inconsistent with (2) and (3).
When a status write error occurs, ContextControl.dead will be set,
(2) will probably be inconsistent with (1) and (3).
Is the above statement correct? Will this inconsistency cause any
problem to software?

2) In page 114, it is said that for IRDMA in packet/buffer mode,
when evt_data_write or evt_overrun occurs, any remaining data in 
the input FIFO for the packet is discarded. When evt_data_err,
evt_short or evt_long occurs, do we need to discard the data of
the packet in the input FIFO?

Thanks for your help,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	DavidW@bangate.compaq.com
Sent:	Monday, December 30, 1996 7:44 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Error handling in OHCI0.9

See below.

David Wooten

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, all:
| 
| I have two questions about DMA error handling in OHCI0.9:
| 
| 1) For a Rx DMA, there are three places that keep the xferStatus, i.e.,
| the one in the ContextControl register in the chip(1), the one in the
| descriptor list(2) and the one in the data buffer(3) in system.
| For buffeFill-mode Rx DMA,
| When a data write error occurs, ContextControl.dead will be set, 
| status will not be updated for the descriptor, therefore,
| (1) will be inconsistent with (2) and (3).
| -- for packet/buffer mode, dead will not be set, (1)(2)(3) will be
| -- consistent.
| When a descriptor read error occurs, ContextControl.dead will be set, 
| (1) will probably be inconsistent with (2) and (3).
| When a status write error occurs, ContextControl.dead will be set,
| (2) will probably be inconsistent with (1) and (3).
| Is the above statement correct? Will this inconsistency cause any
| problem to software?

When dead is set, SW knows to look at the status in ContextControl.  This 
status will resolve any possible ambiguities.  On a descriptor read error, 
ack/err code is set to evt_descriptor_read; on a data write error, ack/err 
code is set to evt_data_read. When ack/err is set to either of these values it 
indicates that the status in 2 or 3 are not valid.
| 
| 2) In page 114, it is said that for IRDMA in packet/buffer mode,
| when evt_data_write or evt_overrun occurs, any remaining data in 
| the input FIFO for the packet is discarded. When evt_data_err,
| evt_short or evt_long occurs, do we need to discard the data of
| the packet in the input FIFO?

We need to rationalize the error codes that we have defined.  Right now, the 
description of evt_short_packet and evt_long_packet indicate that they are 
used on packet/buffer when the data length does not match data_length.  That 
condition is supposed to result in ack_data_error.  evt_long_packet is 
supposed to be used when the data length is longer than the buffer and 
evt_short_packet is supposed to be used when the data length is shorter than 
the packet.  evt_short_packet is really not needed but evt_long_packet is (to 
differentiate between a packet that just fits and one that overflows the 
buffer.)   If the packet is shorter than the buffer, there is nothing extra to 
discard.  If the packet is longer than the buffer, the excess is discarded and 
evt_long_packet should be set.


| 
| Thanks for your help,
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	shuming@sis.com.tw
Sent:	Tuesday, December 31, 1996 5:36 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw; cylin@sis.com.tw
Subject:	ITDMA descriptor question(OHCI0.9)

Hi, all,

  I have some questions about IRDMA descriptor using. Please correct 
my statement if I am wrong.

  (1) Since OUTPUT_MORE_Quadlet must be used to specify the 
isochronous header for a non-zero data length packet, and the 
skipAddress is only used within the first command descriptor in a 
descriptor block. SO, the skipAddress field in 
OUTPUT_MORE descriptor should be deleted.

  (2) Since a single OUTPUT_LAST(w/o other OUTPUT*) in a 
descriptor block is only used for non-transmit cycle, the 3rd quadlet 
of OUTPUT_LAST should be renamed to branchAddress
(follow a STORE_VALUE) OR skip and branch 
address(first in a descriptor block). 

  (3) In a non-transmit cycle, will S/W need to know the occurance of 
cycle lost? If yes,  S/W use OUTPUT_LAST for a non-transmit cycle, 
but also need to specify a different skipAddress rather than 
branchAddress, it seems S/W need to use an extra  STORE_VALUE 
in front of it. By doing so, the PCI cycle will be wasted, am I right?

Thanks for your help. 
From:	DavidW@bangate.compaq.com
Sent:	Thursday, January 02, 1997 1:41 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: ITDMA descriptor question(OHCI0.9)

Please see below for answere/comments.

David Wooten

shuming@sis.com.tw Wrote:
| 
| Hi, all,
| 
|   I have some questions about IRDMA descriptor using. Please correct 
| my statement if I am wrong.
| 
|   (1) Since OUTPUT_MORE_Quadlet must be used to specify the 
| isochronous header for a non-zero data length packet, and the 
| skipAddress is only used within the first command descriptor in a 
| descriptor block. SO, the skipAddress field in 
| OUTPUT_MORE descriptor should be deleted.

You are correct.  Figure 9-1 should not have a skip address in it.

| 
|   (2) Since a single OUTPUT_LAST(w/o other OUTPUT*) in a 
| descriptor block is only used for non-transmit cycle, the 3rd quadlet 
| of OUTPUT_LAST should be renamed to branchAddress
| (follow a STORE_VALUE) OR skip and branch 
| address(first in a descriptor block).

I don't think we have specified how one defines a null packet (no header or 
data.)  It seems to me that an OUTPUT_LAST with a 0 length reqCount could be 
used to denote a non-existant packet as you point out.  In this case, the skip 
address and the branch address are the same (as in OUTPUT_LAST_QUADLET.)
 
| 
|   (3) In a non-transmit cycle, will S/W need to know the occurance of 
| cycle lost? If yes,  S/W use OUTPUT_LAST for a non-transmit cycle, 
| but also need to specify a different skipAddress rather than 
| branchAddress, it seems S/W need to use an extra  STORE_VALUE 
| in front of it. By doing so, the PCI cycle will be wasted, am I right?

Skipping a cycle (cycle lost) fulfils the goals of a null packet in that no 
header or data is sent during a cycle.  Therefor, a cycle lost is a 
'successful' null packet and S/W doen't need to be notified how the hardware 
managed to send nothing on a particular cycle.


| 
| Thanks for your help. 
| 
From:	Frank Campbell [f_campbell@qlc.com]
Sent:	Monday, January 06, 1997 10:51 AM
To:	1394ohci-l
Subject:	Re: -No Subject-

unsubscribe
From:	DavidW@bangate.compaq.com
Sent:	Monday, January 06, 1997 10:48 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re:DMA questions in OHCI0.9

John Fuller pointed out that, in an earlier response to this email, I gave an 
incorrect/misleading response to question number 2.  Please see below for what 
I think is the correct answer.

David


cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, all:
| 
| I have a few questions about DMA in OHCI0.9:
| 
| 1) For AT, software used to provide the branch address for retry.
| But now the command.branchAddress field always indicates the branch
| address for the next descriptor block, thus next packet. Does this
| imply that hardware needs to handle retry branch back itself?
|
| 
| 2) For AT, during bus reset, AT will end the current data
| transmission and then clears contextControl.active. Software 
| will not clear IntEvent.busReset until both AT contexts clear
| the contextControl.active bit. Will software clear 
| contextControl.run before IntEvent.busReset is cleared? If not,
| problem may arise after AT clears active. At that time, because
| dead is not set and run is set, AT controller may try to fetch
| the next descriptor block w/ an invalid commandPtr.
|

Yes, SW will clear contextControl.run in both AT request and AT response 
contexts and wait for both pause bits to be cleared befor it will reset 
IntEvent.busReset.  However, the HC is not required to automaticlly clear 
pause as a result of IntEvent.busReset being set; but it must block the start 
of any new AT packet while IntEvent.busReset is set regardless of the setting 
of active (can't leave any AT packet in the output FIFO either.)

| 
| 3) About CommandPtr, on page 17, it is stated that "If read after
| ContextControl.run has been set, then CommandPTR.descriptorAddress
| will contain the address of the next descriptor that will be 
| accessed..." However, for AT retry and AR/IR back-out, the actual
| next descrptor to be accessed cannot be determined until the 
| command completion. Will this cause any problem to software?
| 
| Thanks for your help,
| 
| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Tuesday, January 07, 1997 9:51 AM
To:	1394ohci-l
Subject:	Greetings - New Names Added

Greetings,

   The attendees of the last two OpenHCI conferences
have their names added to the reflector at this time.

  Best Regards,
  Lee Wilson
From:	shuming@sis.com.tw
Sent:	Wednesday, January 08, 1997 12:59 AM
To:	1394ohci-l@austin.ibm.com
Subject:	How to Distinguish PHY and BUS_RESET PKTs

 Hi, all, 
 
   I have a question about how to distinguish PHY and BUS_RESET PKTs.
 
   Page 75 says:"Software can distinguish the bus-reset packet from 
 authentic PHY packets by checking the value of errCode. A value of
 5'19 identifies this as a bus-reset packet."
 
   Is it possible that a PHY packet set R=1,T=1,Gap_Count=0x26? If 
 yes, shall the LINK side need to generate the unused fields of 2th
 and 3rd quadlets to form a non-inverse pair in bus-reset packet? 
 
   Another question is why not specify the length of bus-reset to 4 
 quadlets, or choose another reserved tCode rather than 0xE, so the
 driver can easily distinguish which kind of packet it is.  
   
   Thanks for your answer.
From:	sakurai@prd.snec.nec.co.jp
Sent:	Tuesday, January 07, 1997 5:11 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Page size


 Hello.

 I have a question about 1394OHCI draft0.9.

 How many length should I implement to Address Counter 
 of DMA controllers  ?
 
 I think that it is depended on Page size.
 And I think DMA data not across Page boundaries.

 How many Page size is supported on 1394OHCI ?


 Thanks for your any comments.


 Toshimi Sakurai

From:	DavidW@bangate.compaq.com
Sent:	Wednesday, January 08, 1997 7:08 AM
To:	sakurai@prd.snec.nec.co.jp; 1394ohci-l@austin.ibm.com
Subject:	re: Page size

Currently, OpenHCI has no notion of page size that it imposes on SW.  If a 
buffer crosses a page boundary but the pages are physically contiguous then SW 
can describe this transfer with a single descriptor block.  I guess this means 
that one needs to implement 32-ish bits of address counter.

David


sakurai@prd.snec.nec.co.jp Wrote:
| 
| 
|  Hello.
| 
|  I have a question about 1394OHCI draft0.9.
| 
|  How many length should I implement to Address Counter 
|  of DMA controllers  ?
|  
|  I think that it is depended on Page size.
|  And I think DMA data not across Page boundaries.
| 
|  How many Page size is supported on 1394OHCI ?
| 
| 
|  Thanks for your any comments.
| 
| 
|  Toshimi Sakurai
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, January 08, 1997 6:56 AM
To:	shuming@sis.com.tw; 1394ohci-l@austin.ibm.com
Subject:	re: How to Distinguish PHY and BUS_RESET PKTs

I think we need to follow your suggestion and make the length of the reset 
token 4 quadlets instead of only 3 quadlets.  This, as you point out, 
eliminates the ambiguity about the token.

David

shuming@sis.com.tw Wrote:
| 
|  Hi, all, 
|  
|    I have a question about how to distinguish PHY and BUS_RESET PKTs.
|  
|    Page 75 says:"Software can distinguish the bus-reset packet from 
|  authentic PHY packets by checking the value of errCode. A value of
|  5'19 identifies this as a bus-reset packet."
|  
|    Is it possible that a PHY packet set R=1,T=1,Gap_Count=0x26? If 
|  yes, shall the LINK side need to generate the unused fields of 2th
|  and 3rd quadlets to form a non-inverse pair in bus-reset packet? 
|  
|    Another question is why not specify the length of bus-reset to 4 
|  quadlets, or choose another reserved tCode rather than 0xE, so the
|  driver can easily distinguish which kind of packet it is.  
|    
|    Thanks for your answer.
| 
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Wednesday, January 08, 1997 3:38 AM
To:	1394ohci-l
Cc:	toni
Subject:	1394 OpenHCI Workshop Dates, etc.

Greetings,

   The 1394 OpenHCI workshop will be at Cirrus Logic 
(Silicon Valley - Fremont, CA as I recall) on Jan. 29 and 
30.  The purpose of this workshop is to go over issues, 
concerns, questions, etc. etc. that the 1394 developers
community has with the .9 level of the OpenHCI 
specification.  It is probably also a good place to discuss
interlocking schedules and plans with software and 
system vendors, etc. etc.

   Since the purpose of this workshop is to meet your needs
in developing 1394 OpenHCI devices, I would like to request
that you send me notes with topics that you want to see on
the agenda.  I think this is the best way to be sure the 
workshop addresses what you really want and need.
My id is leew@austin.ibm.com.  When we have a critical mass
of suggestions, I will post a tentative agenda to the 1394ohci-l
reflector for comment.

   Thanks,
   Lee Wilson 
From:	mis@aluxs.micro.lucent.com
Sent:	Wednesday, January 08, 1997 10:59 AM
To:	1394ohci-l@austin.ibm.com
Cc:	mshinkarovsky@lucent.com
Subject:	Questions/comments on 0.9 OHCI spec

Hi all,
Here is an assembly of questions and comments for draft 0.9 1394 OHCI spec. I appreciate any and all answers.

Questions:
Sec 1.3.2 First Paragraph: could someone enumerate "SIX" DMA controllers? I can count more in the table that follows and less in the supporting sections.

Sec 3.2.2 Flowchart "run=1? -> no" branch: Why not set Active=0 here before "done"?
Does "set cmd=branch addr" imply anymore action then is on a flow chart?

Sec 7.3: Does "Retry" mean that this descriptor block is the very next thing this context is going to re-process?

Sec 8.4.2 Para 8: "Software does not have to initialize resCount....first packet arrival". How does HW know when the first packet arrives into the buffer, if SW never initialized resCount?
Para "3)": are "2)" and "3)" the same xferStatus and resCount or different? It is not clear from the wording present.

Sec 9.1.1 Third para: Should "transmit header" be "transmit trailer"?

Sec 9.1.3 Last para: Why is this a requirement? Why couldn't SW use a bunch of Out_More_Quad strung together?

Sec 10.2.2.1 First para: Doesn't the value of "s" field impose additional condition on update action?
Third para: it is implied that xferStatus and resCount are not updated on overflow. Correct?

Sec 11.2 Table 11-2: What action initializes selfIDGeneration? Is there any syncronization between nodes as far as selfIDGeneration field goes? Does selfIDSize field include generation counter quadlet?



Comments:
Sec 7.1.2 First para, Last para and figure 7-2 inconsistent: paragraphs talk about 1-4 quadlets, but figure specifies reqCount=12 or 16 bytes.

Sec 7.1.3 vs 7.1.4: Wording for "timeStamp" field is not the same between these 2 sections. It appears that it should be the same.

Sec 8.3.2 Table 8-2: "dead", "active" need to be "ru".

Sec 8.4.2 "a)" para: replace "status quadlet" by "packet trailer".

Sec 8.4.2.3 Next to last and last paragraphs: "5'h16" should be 5'h19. "AR Request FIFO" should be "AR Request Buffer".

Sec 8.6.4 Figure 8-16: third and fourth quadlet of the figure are not described in text. Text in fact talks about "a single following quadlet".

Sec 9.1.3 Table 9-2: "s" field should not be described in the table; it was not in the figure.

Sec 9.1.7 Para 5: "OUTPUT_LAST-Immediate" should be "OUTPUT_LAST-Quadlet".

Sec 9.2: "IT ContextMatch" used 2 places is not a register in IT DMA.

Sec 9.2.2 Table 9-7: description for "cycleMatchEnable" refers to "contextMatch register". It should refer to "ContextControl register".

Sec 9.3: "one descriptor from" should be "one descriptor block from".

Sec 9.5 Figure 9-10 title: "Receive" should be "Transmit".
Table 9-8: Description of tcode is missing.

Sec 10.2.1 Para "3)": Change "write the trailer" to "conditionally write the trailer" since that is controlled by isochHeader=1.

Sec 10.2.2.1 first para vs. Fig 10-11: Sec 10.2.2.1 implies that packet trailer is stored LAST into memory for a received packet. Figure 10-11 shows the first quadlet of the packet as the same as packet trailer. Is Fig 10-11 incorrect?

Sec 10.3.2 Table 10-3: In description for "multiChanMode" "IRDMA context control register" should be "IRDMA context match register".

Sec 10.3.3 last para: context will wait forever only if w=2'b11.

Sec 10.4.3 second para: This statement is inconsistent with Sec 10.3.2 Table 10-3 "multiChanMode" third para.

Sec 10.6 Table 10-5: description for "timeStamp" is inconsistent with Sec 10.3.2 Table 10-3 description for "isochHeader". In one timeStamp is time this quadlet is generated, in the other it is timeStamp of cycle_start message. If they are the same, spec should be clear about it.

Sec 11.2 Table 11-2": All fields should be marked as "ru".
Sec 11.2 second para: "written as the first quadlet" should be "written into memory as the first quadlet".

Sec 12 Para "c)5)": Even with upper address of Config Rom changed to 48'hFFFFF00008FC, the space adressed is 1256 bytes (greater than 1K bytes).

Sec 12.2 first para: change "will send ack_complete" to "may send ack_complete".

Sec 12.3: Under error conditions Physical Request handling will generate an interrupt. It appears that this one line section is redundant.           


Typos:
Sec B.3.1 second para: change "listsc" to "lists".


Thank you for your time again,
Michael Shinkarovsky
From:	Patrick_Yu@el.nec.com
Sent:	Wednesday, January 08, 1997 3:19 PM
To:	1394ohci-l@austin.ibm.com; Lee Wilson
Cc:	toni@skipstone.com
Subject:	Re: 1394 OpenHCI Workshop Dates, etc.

Lee,

Given the opportunity, I would like to suggest that the "Compatibility Issue" be
addressed.

I would say that this will needed to be addressed at both the hardware and 
software perspective.  Do we want to leave this to the individual OpenHCI 
developers and risk the possibility of uncertainty, or do we need to have some 
clear guidelines and consensus right at the beginning, no matter how preliminary
those might be?  And it will be extremely helpful to arrange for the 
"Compatibility Workshops" in the near future, especially after the initial 
silicons are sampled.

I hope this subject will be accepted by the committee of OpenHCI.  Thanks.

Yours sincerely,
W.S.P. Yu
NEC Electronics Inc.

______________________________ Reply Separator _________________________________
Subject: 1394 OpenHCI Workshop Dates, etc.
Author:  Lee Wilson <leew@austin.ibm.com> at INTERNET
Date:    1/8/97 9:57 AM


Greetings,

   The 1394 OpenHCI workshop will be at Cirrus Logic 
(Silicon Valley - Fremont, CA as I recall) on Jan. 29 and 
30.  The purpose of this workshop is to go over issues, 
concerns, questions, etc. etc. that the 1394 developers
community has with the .9 level of the OpenHCI 
specification.  It is probably also a good place to discuss
interlocking schedules and plans with software and 
system vendors, etc. etc.

   Since the purpose of this workshop is to meet your needs
in developing 1394 OpenHCI devices, I would like to request
that you send me notes with topics that you want to see on
the agenda.  I think this is the best way to be sure the 
workshop addresses what you really want and need.
My id is leew@austin.ibm.com.  When we have a critical mass
of suggestions, I will post a tentative agenda to the 1394ohci-l
reflector for comment.

   Thanks,
   Lee Wilson 

From:	cylin@sis.com.tw
Sent:	Thursday, January 09, 1997 4:22 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw; shuming@sis.com.tw
Subject:	Bad Z value

Hi, all:

I have a question about Bad Z value:

In page 17 in OHCI0.9, it said that "When software sets ContextControl.run
and CommandPtr.Z contains an invalid value for the controller and context
(e.g. not equal to 1 for asynchronous receive or set to 0), the Host
Controller will set ContextControl.dead and not process any descriptors 
in that context." Since Z equal to 0 indicates the end of the descriptor
list, should HC set dead when it completes processing the last descriptor?
If so, then wake mechanism will be useless. Or does the above statement
require only that Z value is checked right after run is set? If so,
then HC may work incorrectly when a bad Z value is found during the 
period run is set. It seems to be more reasonable that Z=0 is checked
right after run is set, and other bad Z values are checked during the
period run is set. Also, when dead is set because of a bad Z value,
what should the error code be? evt_unknown? Does software needs to be
aware of setting a bad Z value?

Thanks for your time and answers,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	DavidW@bangate.compaq.com
Sent:	Thursday, January 09, 1997 7:01 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Bad Z value

The Z value in the CommandPtr.Z is only the 'initial' Z value (i.e. the Z 
value for the first descriptor fetched when ContextControl.run is set.)  
CommandPtr.Z has no defined meaning after the initial fetch.

During processing, it is envisioned, but not required, that 
CommandPtr.descriptorAddress will not be loaded if the Z value of the branch 
address is 0.  Instead, descriptorAddress would be left pointing at the 
address of the branch (or the descriptor containing the branch.)  Then, when 
ContextControl.wake is written, the HC can refetch the branch address to see 
if the Z value is still 0.  If not, the branch address is loaded into 
CommandPtr and processing resumes.  Using this method, the Z value that is 
loaded into CommandPtr by the HC is never 0.  If one doesn't do it this way, 
an extra commandPtr is required for each context.

David Wooten

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, all:
| 
| I have a question about Bad Z value:
| 
| In page 17 in OHCI0.9, it said that "When software sets ContextControl.run
| and CommandPtr.Z contains an invalid value for the controller and context
| (e.g. not equal to 1 for asynchronous receive or set to 0), the Host
| Controller will set ContextControl.dead and not process any descriptors 
| in that context." Since Z equal to 0 indicates the end of the descriptor
| list, should HC set dead when it completes processing the last descriptor?
| If so, then wake mechanism will be useless. Or does the above statement
| require only that Z value is checked right after run is set? If so,
| then HC may work incorrectly when a bad Z value is found during the 
| period run is set. It seems to be more reasonable that Z=0 is checked
| right after run is set, and other bad Z values are checked during the
| period run is set. Also, when dead is set because of a bad Z value,
| what should the error code be? evt_unknown? Does software needs to be
| aware of setting a bad Z value?
| 
| Thanks for your time and answers,
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Thursday, January 09, 1997 2:25 AM
To:	1394ohci-l
Subject:	-No Subject-

Greetings,

   Since we are going to be more "implementation"
oriented and less "architecture" oriented, I would suggest
that some implementation ideas with minimal FIFOs be 
discussed at the OpenHCI developers workshop.  There may
be other implementation examples and discussions which
are of interest.

   Comments welcome.  The objective is to help you implement
as quickly as possible.

   Best Regards,
   Lee 
From:	DavidW@bangate.compaq.com
Sent:	Thursday, January 09, 1997 9:34 AM
To:	mis@aluxs.micro.lucent.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Questions/comments on 0.9 OHCI spec

 Michael,

I'll answer the ones I can.  See below.

BTW,  this was a really good review.  Thanks a lot!  Now, if we can only get 
about 12 more people to go through it like this, we might find most of the 
errors.

David Wooten

mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| Hi all,
| Here is an assembly of questions and comments for draft 0.9 1394 OHCI spec. 
I 
| appreciate any and all answers.
| 
| Questions:
| Sec 1.3.2 First Paragraph: could someone enumerate "SIX" DMA controllers? I 
can 
| count more in the table that follows and less in the supporting sections.

The table shows  "six, independent programmable DMA controllers" (AT Request, 
AT Response, AR, Iso Tx, Iso Rx, and Self-ID) and two non-programmable 
controllers (phys receive and phys respone.)  The table is a bit inaccurate in 
that there is no 'context' for phys receive and phys response.

| 
| Sec 3.2.2 Flowchart "run=1? -> no" branch: Why not set Active=0 here before  
"done"?

Good point.  If run is not set then HC should make sure that active is 0 to 
complete handshake with SW.


| Does "set cmd=branch addr" imply anymore action then is on a flow chart?

Like what?  This is to indicate that the branch address in a descriptor is 
valid (Z != 0) so CommandPtr.descriptorAddress can be loaded with the branch 
address and Z value of the descriptor.  I think that's all that is required 
here and I believe that this is what the flow chart says.

| 
| Sec 7.3: Does "Retry" mean that this descriptor block is the very next thing 

| this context is going to re-process?

Yes.

| 
| Sec 8.4.2 Para 8: "Software does not have to initialize resCount....first 
packet 
| arrival". How does HW know when the first packet arrives into the buffer, if 
SW 
| never initialized resCount?

When the HC follows a link to fetch a descriptor it knows that the next thing 
that it writes to the buffer described by that descriptor is the 'first' thing 
in that buffer.  When/if a descriptor is refetched, what is written is not the 
'first' thing.

| Para "3)": are "2)" and "3)" the same xferStatus and resCount or different? 
It 
| is not clear from the wording present.

This is to cover the case where a packet crosses a descriptor boundary.  When 
it does, there is a "first' descriptor (the one where the first byte of the 
packet was written, and a 'last' descriptor (the one where the trailer quadlet 
is written.)  If the packet does not have an error, update the xferStatus and 
resCount in the 'last' descriptor before updating the xferStatus and resCount 
in the 'first' descriptor.

| 
| Sec 9.1.1 Third para: Should "transmit header" be "transmit trailer"?

There is no such thing as an isochronous trailer to transmit.  An 
OUTPUT_LAST-Quadlet command is used to send an isochronous header with no data 
payload.

| 
| Sec 9.1.3 Last para: Why is this a requirement? Why couldn't SW use a bunch 
of 
| Out_More_Quad strung together?

This is to provide a hardware simplification.  Headers are always provided in 
an 'immediate. (OUTPUT_MORE-Quad or OUTPUT_MORE_Immediate) and data blocks are 
always described by a descriptor with a address and length.


| 
| Sec 10.2.2.1 First para: Doesn't the value of "s" field impose additional 
| condition on update action?

Yes.  S must be 1 to get accurate values.

| Third para: it is implied that xferStatus and resCount are not updated on 
| overflow. Correct?

No.  This paragraph is in error.  When an buffer overrun occurs, xferStatus 
and resCounts are updated with xferStatus.ack set to evt_long_packet.  The 
value of resCount is a don't care if evt_long_packet is set but writting 
resCount to 0 is probably a good idea.

| 
| Sec 11.2 Table 11-2: What action initializes selfIDGeneration? Is there any 
| syncronization between nodes as far as selfIDGeneration field goes? Does 
| selfIDSize field include generation counter quadlet?

selfIDGeneration is initiated by a 1934 bus reset.

The selfIDGeneration is only used to let SW know that it is working on the 
current generation of the selfID table.  A bus reset can occur while SW is 
parsing the table.  So, SW reads the generation number before starting the 
parsing and then checks the current value of the generation number 
periodically to make sure that another reset hasn't occured since parsing 
started.  This is not coordinated between nodes.

selfIDSize includes the generation counter quadlet.

| 
| 
| 
| Comments:
| Sec 7.1.2 First para, Last para and figure 7-2 inconsistent: paragraphs talk 

| about 1-4 quadlets, but figure specifies reqCount=12 or 16 bytes.

Thanks, but I think its worse that that.  An OUTPUT_MORE_Immediate is only 
used when there is a data block.  I believe that the header for these is 
always 16 bytes so the only valid value for OUTPUT_MORE_Immediate is 16.

| 
| Sec 7.1.3 vs 7.1.4: Wording for "timeStamp" field is not the same between 
these 
| 2 sections. It appears that it should be the same.

Nope.  They should not be the same.  Actually, there is no timeStamp field in 
an OUTPUT_LAST.  Figure 7-3 "OUTPUT_LAST descriptor format" should show the 
timeStamp area of the descriptor as a shaded area.

| 
| Sec 8.3.2 Table 8-2: "dead", "active" need to be "ru".

Yes. Thanks.

| 
| Sec 8.4.2 "a)" para: replace "status quadlet" by "packet trailer".

Yes.

| 
| Sec 8.4.2.3 Next to last and last paragraphs: "5'h16" should be 5'h19. "AR 
| Request FIFO" should be "AR Request Buffer".

Correct about the code being 5'h19.  

The last paragraph is correct but, evidently, not very clear.  If the input 
FIFO is full when a reset occurs, the link side of the FIFO must remember to 
stick a reset token in the FIFO when space becomes available.  When the reset 
token hits the system side of the FIFO, I'm not sure what is supposed to 
happen if ther is no room in the AR request buffer.

Oh, one other thing.  The format of the Bus Reset Packet is not correct.  It 
should be 4 quadlets long with the packet trailer in the last quadlet.

| 
| Sec 8.6.4 Figure 8-16: third and fourth quadlet of the figure are not 
described 
| in text. Text in fact talks about "a single following quadlet".

The figure is correct and the text is wrong.  The PHY receive packet is 4 
quadlets long with the first quadlet containing a tcode of 4'hE.  The second 
quadlet contains the PHY quadlet and the third quadlet should contain the 
inverse of the first qualdet (SW should check.)  The last fourth qualdet 
contains the standard trailer quadlet.

The reason that we don't strip the check quadlet is that any packet that is 
one quadlet plus a check quadlet is assumed to be a PHY packet if the CRC does 
not check.  This means that if an isochronous packet is receive with a zero 
length data packet and the CRC fails, the link is going to assume that it is a 
PHY packet and put it into the FIFO taged as a PHY packet.

| 
| Sec 9.1.3 Table 9-2: "s" field should not be described in the table; it was 
not 
| in the figure.

I agree.

| 
| Sec 9.1.7 Para 5: "OUTPUT_LAST-Immediate" should be "OUTPUT_LAST-Quadlet".

Correct.

| 
| Sec 9.2: "IT ContextMatch" used 2 places is not a register in IT DMA.

Correct.  This is a result of doing some cut&paste from the IR description.  
There is no ContextMatch register in an  isochronous transmit context.

| 
| Sec 9.2.2 Table 9-7: description for "cycleMatchEnable" refers to 
"contextMatch 
| register". It should refer to "ContextControl register".

Correct.  Again, a cut&paste error.

| 
| Sec 9.3: "one descriptor from" should be "one descriptor block from".

Yes, and "the current descriptor" should read "the current descriptor block".

| 
| Sec 9.5 Figure 9-10 title: "Receive" should be "Transmit".
| Table 9-8: Description of tcode is missing.

Correct on both.  Also, it should be noted that the first quadlet (the packet 
header) is _not_ in the data buffer.  It is provided by the first 
OUTPUT_*_Quadlet; and the padding is provided by the HC.  Finally, the staring 
address of the isochronous data does not have to be on a quadlet boundary.  It 
can start on any byte address.  The HC will 'align' and pad it.

| 
| Sec 10.2.1 Para "3)": Change "write the trailer" to "conditionally write the 

| trailer" since that is controlled by isochHeader=1.


Correct.

| 
| Sec 10.2.2.1 first para vs. Fig 10-11: Sec 10.2.2.1 implies that packet 
trailer 
| is stored LAST into memory for a received packet. Figure 10-11 shows the 
first 
| quadlet of the packet as the same as packet trailer. Is Fig 10-11 incorrect?

Fig 10-11 is for packet/buffer mode and is correct, mostly.  In this mode, a 
timestamp is prepended to the packet header so that the timestamp can be saved 
(there is no place in the descriptor to put a timestamp.)  We put the 
timestamp at the start of the stream so that we can save the header with 
timestamp at the same time.  If we left it at the end, we would have an extra 
host bus cycle to save the timeStamp and we wanted to avoid that.  The 
'incorrect' part of Fig 10-11 is that the xferStatus porion doesn't really 
have any meaning for the packet.  Its not 'reserved' because its going to get 
the 'current' value of xferStatus which is not going to be relevant to the 
current packet.

| 
| Sec 10.3.2 Table 10-3: In description for "multiChanMode" "IRDMA context 
control 
| register" should be "IRDMA context match register".

Correct.

| 
| Sec 10.3.3 last para: context will wait forever only if w=2'b11.

'Wait' is not quite right.  If the tag doesn't match, no data is received for 
the context.  Descriptors are not used up and the descriptor program doesn't 
advance.  This is kind of a wait but we shouldn't say that because we do have 
a W field.

| 
| Sec 10.4.3 second para: This statement is inconsistent with Sec 10.3.2 Table 

| 10-3 "multiChanMode" third para.

The text in 10.4.3 is correct and Table 10-3 is wrong.

| 
| Sec 10.6 Table 10-5: description for "timeStamp" is inconsistent with Sec 
10.3.2 
| Table 10-3 description for "isochHeader". In one timeStamp is time this 
quadlet 
| is generated, in the other it is timeStamp of cycle_start message. If they 
are 
| the same, spec should be clear about it.

Yes, we need to make sure we get this right.  I believe that the timeStamp for 
the isochronous receive data should come from the cycleStart (or from 
synthesized cycleStart if cycle missing.)  This value can be used for both 
asynchronous receive and isochronous receive timeStamps.  If there is no cycle 
master, then the HC will end up using the synthesized value all the time and 
we only get asynchronous packets.  We will try to get this clarified by the 
meeting at the end of this month.

| 
| Sec 11.2 Table 11-2": All fields should be marked as "ru".

Yup.

| Sec 11.2 second para: "written as the first quadlet" should be "written into 

| memory as the first quadlet".

OK.

| 
| Sec 12 Para "c)5)": Even with upper address of Config Rom changed to 
| 48'hFFFFF00008FC, the space adressed is 1256 bytes (greater than 1K bytes).

Hum, seems that both this number and the value in Table 5-9 are both wrong 
(anyone got a hex calculator they want to lend us?)  Let's see, ROM space 
starts at 48'FFFF_F000_0400 and is 1K (16'h400) long.  That means it stops at 
48'FFFF_F000_07FF.

| 
| Sec 12.2 first para: change "will send ack_complete" to "may send 
ack_complete".

Correct.

| 
| Sec 12.3: Under error conditions Physical Request handling will generate an 
| interrupt. It appears that this one line section is redundant.           

Uh, physical read handling does not cause an interrupt.  Physical write 
handling may cause and interrupt if there is a posting error.  Clearly, we 
need to fix this paragraph.

| 
| 
| Typos:
| Sec B.3.1 second para: change "listsc" to "lists".
| 
| 
| Thank you for your time again,
| Michael Shinkarovsky
| 
From:	shuming@sis.com.tw
Sent:	Friday, January 10, 1997 5:34 AM
To:	1394ohci-l@austin.ibm.com
Cc:	shuming@sis.com.tw
Subject:	Re: ITDMA descriptor question(OHCI0.9)


Hi, all,

  I am not sure if this message has been received by reflector, so I 
add some comments and resend it. I appreciate any and all answers. 

  I have some questions about IRDMA descriptor using. Please correct 
my statement if I am wrong.

  (1) Since OUTPUT_MORE_Quadlet must be used to specify the 
isochronous header for a non-zero data length packet, and the 
skipAddress is only used within the first command descriptor in a 
descriptor block. SO, the skipAddress field in 
OUTPUT_MORE descriptor should be deleted.

  (2) Since a single OUTPUT_LAST(w/o other OUTPUT*) in a 
descriptor block is only used for non-transmit cycle, the 3rd quadlet 
of OUTPUT_LAST should be renamed to branchAddress
(follow a STORE_VALUE) OR skip and branch 
address(first in a descriptor block). 

  (3) In a non-transmit cycle, will S/W need to know the occurance of 
cycle lost? If yes,  S/W use OUTPUT_LAST for a non-transmit cycle, 
but also need to specify a different skipAddress rather than 
branchAddress, it seems S/W need to use an extra  STORE_VALUE 
in front of it. By doing so, the PCI cycle will be wasted, am I right?

Other comments about OHCI0.9:
(1) Page 49, Sec7.1 para 2 "one OUTPUT_MORE-Immediate descriptor 
followed by zero to six OUTPUT_MORE* descriptors, followed by one 
OUTPUT_LAST* descriptor" should be changed to  "one OUTPUT_MORE-Immediate descriptor 
followed by zero to FIVE OUTPUT_MORE descriptors, followed by one
OUTPUT_LAST descriptor"

(2) Page 53, only 12 or 16 are allowed in reqCount field.

(3) Fig 7-11,8-12,8-14 should change extendedTcode to 1394reserved.

Thank you for your time. 
From:	mis@aluxs.micro.lucent.com
Sent:	Friday, January 10, 1997 8:25 AM
To:	1394ohci-l@austin.ibm.com
Cc:	mshinkarovsky@lucent.com
Subject:	re: Questions/comments on 0.9 OHCI spec

David,
Thank you for your very thorough answers. I need clarification on a couple of them.

Mike Shinkarovsky writing marked as > |
David Wooten writing marked as >

DavidW@bangate.compaq.com Wrote:
 
> | Sec 8.4.2 Para 8: "Software does not have to initialize resCount....first packet 
> | arrival". How does HW know when the first packet arrives into the buffer, if SW 
> | never initialized resCount?
> 
> When the HC follows a link to fetch a descriptor it knows that the next thing 
> that it writes to the buffer described by that descriptor is the 'first' thing 
> in that buffer.  When/if a descriptor is refetched, what is written is not the 
> 'first' thing.

If HCI HW is designed to move to the next descriptor after the last byte of the preceeding buffer has been filled in (and that byte happens to be the last byte written for a packet received), then HCI HW will not know the difference between a "fetch" and "refetch" of the descriptor, since when the new packet comes in it will have to "fetch/refetch" descriptor pointed by CommandPtr register. So what is HW to do to know the difference between first/not first packet received into the buffer?


> | 
> | Sec 10.2.2.1 first para vs. Fig 10-11: Sec 10.2.2.1 implies that packet trailer 
> | is stored LAST into memory for a received packet. Figure 10-11 shows the first 
> | quadlet of the packet as the same as packet trailer. Is Fig 10-11 incorrect?
> 
> Fig 10-11 is for packet/buffer mode and is correct, mostly.  In this mode, a 
> timestamp is prepended to the packet header so that the timestamp can be saved 
> (there is no place in the descriptor to put a timestamp.)  We put the 
> timestamp at the start of the stream so that we can save the header with 
> timestamp at the same time.  If we left it at the end, we would have an extra 
> host bus cycle to save the timeStamp and we wanted to avoid that.  The 
> 'incorrect' part of Fig 10-11 is that the xferStatus porion doesn't really 
> have any meaning for the packet.  Its not 'reserved' because its going to get 
> the 'current' value of xferStatus which is not going to be relevant to the 
> current packet.

Sec 10.2.2.1 First para states: 
"In packet-per-buffer mode, the xferStatus and resCount fields are updated only in the descriptor for the buffer which receives the last byte of the packet, or if isochHeader mode is enabled, the last byte of the packet trailer."
Table 10-3 isochHeader states:
"The end of the packet will be marked with a xferStatus (bits 15:0 of this register) in the first doublet, and a 16-bit timeStamp indicating the time of the most recently received (or sent) cycleStart packet."
In your description above there is no packet trailer that is written into buffer after the last byte. Do both 10.2.2.1 and 10-3 need to be fixed? Formatting data differently for packet/buffer vs. buffer fill with isochHeader=1 appears inconsistent.

Thanks again,
Michael Shinkarovsky.
From:	mis@aluxs.micro.lucent.com
Sent:	Friday, January 10, 1997 9:30 AM
To:	1394ohci-l@austin.ibm.com
Cc:	mshinkarovsky@lucent.com
Subject:	PCI_Global_Swap bit in OHCI 0.9

Hi all,
Here is a question about section B.4.

In an environment where a preexisting PCI interface logic design does not have a global_swap capability, thus forcing this functionality into OHCI host-end logic, OHCI will have to read this bit from PCI config space and configure itself accordingly.

With that in mind, the spec should address when SW is allowed to write to PCI_HCI_Control Register, to simplify OHCI HW design. This way OHCI would have to read this register only once at a specified time.

Thank you,
Michael Shinkarovsky


 
From:	DavidW@bangate.compaq.com
Sent:	Friday, January 10, 1997 11:34 AM
To:	mis@aluxs.micro.lucent.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Questions/comments on 0.9 OHCI spec

Replies below.

David

mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| David,
| Thank you for your very thorough answers. I need clarification on a couple 
of 
| them.
| 
| Mike Shinkarovsky writing marked as > |
| David Wooten writing marked as >
| 
| DavidW@bangate.compaq.com Wrote:
|  
| > | Sec 8.4.2 Para 8: "Software does not have to initialize 
resCount....first 
| packet 
| > | arrival". How does HW know when the first packet arrives into the 
buffer, if 
| SW 
| > | never initialized resCount?
| > 
| > When the HC follows a link to fetch a descriptor it knows that the next 
thing 
| > that it writes to the buffer described by that descriptor is the 'first' 
thing 
| 
| > in that buffer.  When/if a descriptor is refetched, what is written is not 
the 
| 
| > 'first' thing.
| 
| If HCI HW is designed to move to the next descriptor after the last byte of 
the 
| preceeding buffer has been filled in (and that byte happens to be the last 
byte 
| written for a packet received), then HCI HW will not know the difference 
between 
| a "fetch" and "refetch" of the descriptor, since when the new packet comes 
in it 
| will have to "fetch/refetch" descriptor pointed by CommandPtr register. So 
what 
| is HW to do to know the difference between first/not first packet received 
into 
| the buffer?

If you fetch the descriptor and don't transfer any data to the descriptor, it 
probably would be good to write the xferStatus and resCount values setting 
resCount to reqCount.  If we don't want to require any prefetch and we want to 
avoid this redundant write, we might need to define the initial xferStatus to 
be all 0's.  The HC coult use the fact that active is 0 to know that this is a 
first fetch.  I don' think this is a particular problem to add this to the 
definition as I think we already reccomend that SW initialize xferStatus to 0 
so that SW can tell when something has happened to the descriptor.  So, all we 
would have to do is formalize this into a requirement and then let the HC rely 
on this indicator to denote a first access.

| 
| 
| > | 
| > | Sec 10.2.2.1 first para vs. Fig 10-11: Sec 10.2.2.1 implies that packet 
trailer 
| > | is stored LAST into memory for a received packet. Figure 10-11 shows the 
first 
| > | quadlet of the packet as the same as packet trailer. Is Fig 10-11 
incorrect?
| > 
| > Fig 10-11 is for packet/buffer mode and is correct, mostly.  In this mode, 
a 
| > timestamp is prepended to the packet header so that the timestamp can be 
saved 
| 
| > (there is no place in the descriptor to put a timestamp.)  We put the 
| > timestamp at the start of the stream so that we can save the header with 
| > timestamp at the same time.  If we left it at the end, we would have an 
extra 
| > host bus cycle to save the timeStamp and we wanted to avoid that.  The 
| > 'incorrect' part of Fig 10-11 is that the xferStatus porion doesn't really 

| > have any meaning for the packet.  Its not 'reserved' because its going to 
get 
| > the 'current' value of xferStatus which is not going to be relevant to the 

| > current packet.
| 
| Sec 10.2.2.1 First para states: 
| "In packet-per-buffer mode, the xferStatus and resCount fields are updated 
only 
| in the descriptor for the buffer which receives the last byte of the packet, 
or 
| if isochHeader mode is enabled, the last byte of the packet trailer."

Ah.  This is wrong.  If we are in packet per buffer mode, there is no trailer 
quadlet.

| Table 10-3 isochHeader states:
| "The end of the packet will be marked with a xferStatus (bits 15:0 of this 
| register) in the first doublet, and a 16-bit timeStamp indicating the time 
of 
| the most recently received (or sent) cycleStart packet."

The trailer quadlet only goes into the buffer if it is in buffer fill mode and 
headers are enabled.

| In your description above there is no packet trailer that is written into 
buffer 
| after the last byte. Do both 10.2.2.1 and 10-3 need to be fixed? Formatting 
data 
| differently for packet/buffer vs. buffer fill with isochHeader=1 appears 
| inconsistent.

The descriptions that are in the spec are incorrect.  In packet per buffer, no 
trailer quadlet is available to be written to the buffer.  Instead the a 
quadlet is prepended to the packet and appears in front of the 1394 isoc 
header quadlet (as per Fig 10-11).  The prepended quadlet and the 1394 header 
qualdet are only present if ContextControl.isochHeader is set.  In buffer fill 
mode, setting isochHeader causes the trailer quadlet to be appended (as in Fig 
10-9.)  Fundamentally, I think the figures are correct and the text is 
incorrect.

| 
| Thanks again,
| Michael Shinkarovsky.
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, January 10, 1997 11:45 AM
To:	mis@aluxs.micro.lucent.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Processing Descriptors

Replies embedded below.

David Wooten

mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| David,
| I have a few follow-up questions.
| First two things would help me (and maybe others) with understanding 
flowchart 
| on Fig 3-3.
| 1. It would help to know where descriptor block fetch occurs in the flow.

The actual fetch of the descriptor block occurs in the box marked "process 
descriptor".  A refetch of the branch address in from a previously used 
descriptor occurs in the box marked "get branch addr".

| 2. Where the DMA actually is bursting data (acting upon a descriptor) in the 
 flow.

In the "process descriptor" box (busy little box ain't it).

| 
| > mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| > | 
| > | David,
| > | I was reading your reply about Bad_Z values, and I have questions.
| > | 
| > | What is the meaning of the loop in Fig 3-3 of 0.9 OHCI spec?
| > | Does it mean go to the next context? Reprocess this context again?
| > 
| > The loop only happens on non-iso controllers.  There is only one context 
per 
| > controller for non isochronous things.  So, loop must mean process same 
| > context again.
| 
| What does this flowchart look like for AR controller which has 2 contexts? 

This is a per context flow chart.  The AR controller (which may actually be 
two controllers with 1 context) processes the each context according to the 
flow chart.  The decision about when to start the processing or how processing 
might be interleaved (one controller with each context in a different stage of 
execution -- i.e., concurrent context processing) is left up to the 
implementation.


|  
| > | 
| > | Also what is the difference between "**yields the branch entry of the 
current 
| > | cmd descr" and "***refetch last known cmd's branch entry"?
| > | 
| > | Does block set cmd=branch addr mean "load branch addr and Z into 
CommandPtr 
| > | reg"?
| > 
| > Yes, but to be more specific...
| > 
| > If we active, then we haven't hit a branch with a Z of zero (the "no" path 
out 
| > of active == 0 test.)  When we process the descriptor down that path we 
set 
| > branch address and Z from the descriptor block or we "yield the branch 
entry 
| > of the current cmd descr."  So if the Z value from the branch is 0 we 
don't 
| > update cmd (CommandPtr) but if Z is not 0, we do update CommandPtr so that 

| > next time around, we advance to the next descriptor.
| > 
| > If active was 0, however, we need to refetch from the place where we last 
| > _tried_ to fetch a branch address (when we fetched the branch, Z was 0 so 
we 
| > set active to 0).  If 'wake' is set, we need to go back to that location 
that 
| > used to have a Z == 0 and see if it has changed so we "refetch last know 
cmd's 
| > branch entry".  If that entry still has a Z == 0 then we don't change cmd 
| > (CommandPtr) but if Z != 0, then we can put that fetched value into 
CommandPtr 
| > and continue.
| > 
| > Note that the flow chart indicates that an iso transmit context and an iso 

| > receive in packet/buffer mode will always lose at least one cycle of data 
if 
| > they ever hit a Z==0. 
| 
| If you could explain where fetching of descriptor block happens and where 
| execution of descriptor happens (bursting data), things would look a lot 
less 
| confusing (same request as above).
| 
| Maybe a phone conversation would be beneficial. My number (610)712-2938.

If you still have questions, maybe we need to bring this up at the 
Implementors Workshop (or whatever we are calling the meeting we are having on 
1/29 and 1/30.)  That way, we can make sure everyone understands it the same 
way.

| 
| Thanks very much.
| Mike.
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, January 10, 1997 11:51 AM
To:	1394ohci-l@austin.ibm.com
Subject:	fwd: re: PCI_Global_Swap bit in OHCI 0.9

Comments By: David Wooten@Desktop@PCPD Hou
Originally To: SMTP@PCPD Hou G1@Servers[<mis@aluxs.micro.lucent.com>]
Originally From: David Wooten@Desktop@PCPD Hou
Original Date:  1/10/97  1:49 PM
Comments:



-------------------------[Original Message]--------------------------

Michael,

Wouldn't it be possible to put the "vendor optional' registers in the OHCI 
portion? That way, we don't need to specify any interaction between the HC and 
some PCI logic (the "vendor optional" space is usually not implemented in pre 
existing PCI interface logic anyway and this mostly gets passed on anyway.

David

mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| Hi all,
| Here is a question about section B.4.
| 
| In an environment where a preexisting PCI interface logic design does not 
have a 
| global_swap capability, thus forcing this functionality into OHCI host-end 
| logic, OHCI will have to read this bit from PCI config space and configure 
| itself accordingly.
| 
| With that in mind, the spec should address when SW is allowed to write to 
| PCI_HCI_Control Register, to simplify OHCI HW design. This way OHCI would 
have 
| to read this register only once at a specified time.
| 
| Thank you,
| Michael Shinkarovsky
| 
| 
|  
| 
From:	cylin@sis.com.tw
Sent:	Friday, January 10, 1997 6:07 PM
To:	1394ohci-l@austin.ibm.com

>The Z value in the CommandPtr.Z is only the 'initial' Z value (i.e. the Z 
>value for the first descriptor fetched when ContextControl.run is set.)  
>CommandPtr.Z has no defined meaning after the initial fetch.
>
>During processing, it is envisioned, but not required, that 
>CommandPtr.descriptorAddress will not be loaded if the Z value of the branch 
>address is 0.  Instead, descriptorAddress would be left pointing at the 
>address of the branch (or the descriptor containing the branch.)  Then, when 

Do we do the same thing when the descriptor containing the branch 
contains a bad Z value? Should we set dead bit under this situation?

>ContextControl.wake is written, the HC can refetch the branch address to see 
>if the Z value is still 0.  If not, the branch address is loaded into 
>CommandPtr and processing resumes.  Using this method, the Z value that is 
>loaded into CommandPtr by the HC is never 0.  If one doesn't do it this way, 
>an extra commandPtr is required for each context.
>
>David Wooten
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	shuming@sis.com.tw
Sent:	Saturday, January 11, 1997 4:02 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Question about GUID,BIB,Config_ROM,Expansion ROM

Hi, all,

  I have some questions about expansion ROM,Config_ROM, 
Bus_Informatin_Block, GUID.  I appreciate if you will 
clearify their usage.

If 1394 OHC is on add-in adapter card, my questions are:

(1) Expansion ROM contains BIOS and OpenFirmware, 
GUID should be loaded on a hardware reset, what else should also be 
initialized at this moment? 
       I guess this problem depends on if we need to support 
bootbility. Am I right?

(2) If we implement a seperate GUID ROM, what image should be stored 
in it? Only GUID or whole Bus_Information_Block?  

(3) For those 251 quadlets (from 6th to 256th) of Config_ROM
(or whole 1K size), where
should they be stored? Does they created by driver, or by 
firmware and stored in Expansion Rom? Who should map them? Driver or 
firmware? 
      I guess all these problems depends on if we need to support 
bootbility. If we do not need bootbility, all can be done by driver.
Am I right? 

(4) 
  a. If    ( (VersionRegister.GUID_ROM==1)
      &&   (Serial ROM image stored in seperate Serial ROM))
     {
        1,2,3 quadlet of BIB is set by firmware
        GUID is set by HW                                
     }
     Is it correct?
  b. If    ( (VersionRegister.GUID_ROM==0)
      &&   (Serial ROM image stored in Serial ROM))
     {
        All five BIB is set by firmware                            
     }
     Is it correct?
  c. If    ( (VersionRegister.GUID_ROM==1)
      &&   (Serial ROM image stored in Expansion ROM))
     {
        1,2,3 quadlet of BIB is set by firmware
        GUID is set by HW                                
     }
     Is it correct? If yes, HW need to know the address where it can 
load the image.
  d. If    ( (VersionRegister.GUID_ROM==0)
      &&   (Serial ROM image stored in Expansion ROM))
     {
        All five BIB is set by firmware                            
     }
     Is it correct?



Thank you for your help.
***************************************************************
Shu-Ming Liu                                                 
Software Engineer                                            
Software Design Department                                   
Silicon Integrated Systems Corp.                             
Phone 886-35-774922 ext 4157                                 
Fax   886-35-790651                                          
<mailto> shuming@sis.com.tw                                  
***************************************************************
From:	cylin@sis.com.tw
Sent:	Monday, January 13, 1997 4:40 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Questions/comments on 0.9 OHCI spec

Hi, all:

In reply to Michael Shinkarovsky's questions, David Wooten wrote:
>| 
>| Sec 7.1.3 vs 7.1.4: Wording for "timeStamp" field is not the same between 
>these 
>| 2 sections. It appears that it should be the same.
>
>Nope.  They should not be the same.  Actually, there is no timeStamp field in 
>an OUTPUT_LAST.  Figure 7-3 "OUTPUT_LAST descriptor format" should show the 
>timeStamp area of the descriptor as a shaded area.
For AT request, timeStamp will be placed by HC the transmission time of the
packet. Therefore, it is meaningful to SW (but not HW). If a field in 
a descriptor is shaded because it is not meaningful to HW, then xferStatus
should be shaded, too. I think it's more reasonable to keep timeStamp field
in the OUTPUT_LAST descriptor.

>| 
>| Sec 10.2.2.1 first para vs. Fig 10-11: Sec 10.2.2.1 implies that packet 
>trailer 
>| is stored LAST into memory for a received packet. Figure 10-11 shows the 
>first 
>| quadlet of the packet as the same as packet trailer. Is Fig 10-11 incorrect?
>
>Fig 10-11 is for packet/buffer mode and is correct, mostly.  In this mode, a 
>timestamp is prepended to the packet header so that the timestamp can be saved 
>(there is no place in the descriptor to put a timestamp.)  We put the 
>timestamp at the start of the stream so that we can save the header with 
>timestamp at the same time.  If we left it at the end, we would have an extra 
>host bus cycle to save the timeStamp and we wanted to avoid that.  The 
>'incorrect' part of Fig 10-11 is that the xferStatus porion doesn't really 
>have any meaning for the packet.  Its not 'reserved' because its going to get 
>the 'current' value of xferStatus which is not going to be relevant to the 
>current packet.
>
If xferStatus is not relevant to the current packet, then why this field?
I mean, how SW use this field?

Here are some more questions about OHCI0.9:

1) In section 3.4, Table 3-4, the tcodes for Physical Request should be
0,1,4,5,9,E, instead of only E, correct?

2) In section 7.1.4, the last para. (in page 54) stated that "Typically the
OUTPUT_LAST-Immediate command will be used to specify the 1394 transmit packet
header...", Is it possible that OUTPUT_LAST-Immediate is used to specify
packet data?

3) During the period that the end of the descriptor list is reached and
before ContextControl.wake bit is set, should HC clear ContextControl.active?

Thanks for your time and answers,




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	cmlin@sis.com.tw
Sent:	Tuesday, January 14, 1997 6:17 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw
Subject:	The questions about OHCI0.9

Hi all,

I have questions about OHCI0.9:

DavidW@bangate.compaq.com (David Wooten) Wrote:

>The reason that we don't strip the check quadlet is that any packet
>that is one quadlet plus a check quadlet is assumed to be a PHY packet
>if the CRC does not check.  This means that if an isochronous packet
>is receive with a zero length data packet and the CRC fails, the link
>is going to assume that it is a PHY packet and put it into the FIFO
>taged as a PHY packet.

1.  What packet will be regarded as the PHY packet?  Whether is the
      packet whose size is two quadlets and CRC check is fail regarded
     as a PHY packet, no matter what content in the packet?

2. The descriptions in Table 4-3 (Page 25) about the read value of 
     the IsoTxIntEventClear and IsoRxIntEventClear registers aren't
     consistent with the descriptions in paragraph 3, section 6.2.3 and
     section 6.2.4 (Page 47 ~ 48). Which are right?

3. The description in section B.2 (Page 117) is as "If the busmaster 
    bit in the command register transitions from 1 to zero (see section
    B.3.1), the PCI logic supporting the OpenHCI controller logic
    must kill all DMA contexts."  My question is the action of killing
    all DMA contexts is done by HW or SW?  If it is done by HW,
    how to do it?

Thanks for your time and answer,


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chi-Ming Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4324
Fax: 886-3-5790651
Email: cmlin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From:	mis@aluxs.micro.lucent.com
Sent:	Tuesday, January 14, 1997 7:29 AM
To:	1394ohci-l@austin.ibm.com
Cc:	mshinkarovsky@lucent.com
Subject:	AT FIFO in OHCI 0.9

Hi all,

Sec 1.3.5.1 Second para: "Other sections of this specification will provide implementation guidelines.....". Which other section(s)? I found the section for AR FIFO (sec 3.3).

Thanks,
Michael Shinkarovsky
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, January 14, 1997 10:34 AM
To:	cylin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Bad Z value

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| >The Z value in the CommandPtr.Z is only the 'initial' Z value (i.e. the Z 
| >value for the first descriptor fetched when ContextControl.run is set.)  
| >CommandPtr.Z has no defined meaning after the initial fetch.
| >
| >During processing, it is envisioned, but not required, that 
| >CommandPtr.descriptorAddress will not be loaded if the Z value of the 
branch 
| >address is 0.  Instead, descriptorAddress would be left pointing at the 
| >address of the branch (or the descriptor containing the branch.)  Then, 
when 
| 
| Do we do the same thing when the descriptor containing the branch 
| contains a bad Z value? Should we set dead bit under this situation?

I think we currently state that the behavior is undefined if SW puts a bad Z 
value in the branch address.  I guess having the HC set the dead bit would be 
one of the many allowable undefined behaviors.

| 
| >ContextControl.wake is written, the HC can refetch the branch address to 
see 
| >if the Z value is still 0.  If not, the branch address is loaded into 
| >CommandPtr and processing resumes.  Using this method, the Z value that is 
| >loaded into CommandPtr by the HC is never 0.  If one doesn't do it this 
way, 
| >an extra commandPtr is required for each context.
| >
| >David Wooten
| >
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, January 14, 1997 10:40 AM
To:	daisy@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Questions/comments on 0.9 OHCI spec

daisy@sis.com.tw (Yen-Jiuan Chao) Wrote:
| 
| Hi, 
| 
| I have a question about the answer you replied, you mentioned that, for an
| Isochronous packet with zero length data and header CRC error will be taged
| as a PHY packet. Why should we accept a packet if it has header CRC error ?
| We don't even know the packet header contains the correct information.
| 
| Thanks for your time and answer,
| 
| Y.J. Chao

We accept this _rare_ case as a PHY packet because all PHY packets fail CRC.  
PHY packets are protected by sending two quadlets, the second of which is the 
logical inverse of the first.  Rather than have the link have to do CRC _and_ 
inverse checking (PHY does inverse checking) we simply assume that any two 
quadlet long packet that fails is probably a PHY packet and we stuff it in the 
AR request fifo/buffer.  SW can easily verify that it really is or is not a 
PHY packet.

Note, PHY packets sent during the selfID phase of the bus are put into the 
selfID buffer with no checking of the validity of the packet by the link.


| 
| >| 
| >| Sec 8.6.4 Figure 8-16: third and fourth quadlet of the figure are not 
| >described 
| >| in text. Text in fact talks about "a single following quadlet".
| >
| >The figure is correct and the text is wrong.  The PHY receive packet is 4 
| >quadlets long with the first quadlet containing a tcode of 4'hE.  The 
second 
| >quadlet contains the PHY quadlet and the third quadlet should contain the 
| >inverse of the first qualdet (SW should check.)  The last fourth qualdet 
| >contains the standard trailer quadlet.
| >
| >The reason that we don't strip the check quadlet is that any packet that is 

| >one quadlet plus a check quadlet is assumed to be a PHY packet if the CRC 
does 
| >not check.  This means that if an isochronous packet is receive with a zero 

| >length data packet and the CRC fails, the link is going to assume that it 
is a 
| >PHY packet and put it into the FIFO taged as a PHY packet.
| >
| ====================================
| Yen-Jiuan Chao (Daisy)
| Design Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.(SiS)
| Phone  : 886-3-5774922 ext. 4315
| Fax    : 886-3-5790651
| E-mail : daisy@sis.com.tw
| =====================================
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, January 14, 1997 11:02 AM
To:	cylin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Questions/comments on 0.9 OHCI spec

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, all:
| 
| In reply to Michael Shinkarovsky's questions, David Wooten wrote:
| >| 
| >| Sec 7.1.3 vs 7.1.4: Wording for "timeStamp" field is not the same between 

| >these 
| >| 2 sections. It appears that it should be the same.
| >
| >Nope.  They should not be the same.  Actually, there is no timeStamp field 
in 
| >an OUTPUT_LAST.  Figure 7-3 "OUTPUT_LAST descriptor format" should show the 

| >timeStamp area of the descriptor as a shaded area.
| For AT request, timeStamp will be placed by HC the transmission time of the
| packet. Therefore, it is meaningful to SW (but not HW). If a field in 
| a descriptor is shaded because it is not meaningful to HW, then xferStatus
| should be shaded, too. I think it's more reasonable to keep timeStamp field
| in the OUTPUT_LAST descriptor.

I think we need to show that the timeStamp field in an OUTPUT_LAST for AT 
request is vaid and updated when the request is sent (as is xferStatus) and 
that there is no timeStamp field in an OUTPUT_LAST for AT response but the 
xferStatus field is valid.

| 
| >| 
| >| Sec 10.2.2.1 first para vs. Fig 10-11: Sec 10.2.2.1 implies that packet 
| >trailer 
| >| is stored LAST into memory for a received packet. Figure 10-11 shows the 
| >first 
| >| quadlet of the packet as the same as packet trailer. Is Fig 10-11 
incorrect?
| >
| >Fig 10-11 is for packet/buffer mode and is correct, mostly.  In this mode, 
a 
| >timestamp is prepended to the packet header so that the timestamp can be 
saved 
| >(there is no place in the descriptor to put a timestamp.)  We put the 
| >timestamp at the start of the stream so that we can save the header with 
| >timestamp at the same time.  If we left it at the end, we would have an 
extra 
| >host bus cycle to save the timeStamp and we wanted to avoid that.  The 
| >'incorrect' part of Fig 10-11 is that the xferStatus porion doesn't really 
| >have any meaning for the packet.  Its not 'reserved' because its going to 
get 
| >the 'current' value of xferStatus which is not going to be relevant to the 
| >current packet.
| >
| If xferStatus is not relevant to the current packet, then why this field?
| I mean, how SW use this field?

I'm not sure that SW can use this field.  We didn't want to have this field be 
reserved because that would make it mandantory for the HC to write 0's to the 
field.  Rather than do that, we decided to let the HC write the current value 
of the xferStatus (like it does in other cases of writing the timeStamp) an 
reduce the special casing required in the hardware.

| 
| Here are some more questions about OHCI0.9:
| 
| 1) In section 3.4, Table 3-4, the tcodes for Physical Request should be
| 0,1,4,5,9,E, instead of only E, correct?

Actually, I think that line in the table should be left out because it is 
simply going to be confussing.  The unit that handles physical requests also 
generates responses so all 1394 defined tcodes other than A (isochronous) are 
legitimate.

| 
| 2) In section 7.1.4, the last para. (in page 54) stated that "Typically the
| OUTPUT_LAST-Immediate command will be used to specify the 1394 transmit 
packet
| header...", Is it possible that OUTPUT_LAST-Immediate is used to specify
| packet data?

An OUTPUT_LAST_Immediate can only be used for sending information that is 
protected by the header CRC or for sending a PHY packet.  Sometimes, that 
includes an embeded data quadlet.  There can only be one OUTPUT_*_Immediate 
(AT) or one OUTPUT_*_Qualdet (IT) per descriptor block (e.g., 
OUTPUT_MORE_Immediate followed by OUTPUT_*_Immediate is not allowed.


| 
| 3) During the period that the end of the descriptor list is reached and
| before ContextControl.wake bit is set, should HC clear 
ContextControl.active?

When the HC finds a Z value of 0 in a brach address, it will turn off active.  
Then when it checks the context again and finds active clear but wake set, it 
will refetch from the location that containd the branch with Z = 0.\

| 
| Thanks for your time and answers,
| 
| 
| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, January 14, 1997 11:20 AM
To:	cmlin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: The questions about OHCI0.9

cmlin@sis.com.tw Wrote:
| 
| Hi all,
| 
| I have questions about OHCI0.9:
| 
| DavidW@bangate.compaq.com (David Wooten) Wrote:
| 
| >The reason that we don't strip the check quadlet is that any packet
| >that is one quadlet plus a check quadlet is assumed to be a PHY packet
| >if the CRC does not check.  This means that if an isochronous packet
| >is receive with a zero length data packet and the CRC fails, the link
| >is going to assume that it is a PHY packet and put it into the FIFO
| >taged as a PHY packet.
| 
| 1.  What packet will be regarded as the PHY packet?  Whether is the
|       packet whose size is two quadlets and CRC check is fail regarded
|      as a PHY packet, no matter what content in the packet?

yes.

| 
| 2. The descriptions in Table 4-3 (Page 25) about the read value of 
|      the IsoTxIntEventClear and IsoRxIntEventClear registers aren't
|      consistent with the descriptions in paragraph 3, section 6.2.3 and
|      section 6.2.4 (Page 47 ~ 48). Which are right?

Table 4-3 is 'corrrect' but 6.2.3 is more precise (can't always fit all the 
information in a table.)  Maybe we need to change what we have in the table?


| 
| 3. The description in section B.2 (Page 117) is as "If the busmaster 
|     bit in the command register transitions from 1 to zero (see section
|     B.3.1), the PCI logic supporting the OpenHCI controller logic
|     must kill all DMA contexts."  My question is the action of killing
|     all DMA contexts is done by HW or SW?  If it is done by HW,
|     how to do it?

If the busmater bit is set to 0, the PCI interface should return 'host bus 
error' whenever a DMA tries to access the PCI bus.  This wil cause all active 
contexts to die (dead bit will become set.) 

| 
| Thanks for your time and answer,
| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chi-Ming Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4324
| Fax: 886-3-5790651
| Email: cmlin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, January 14, 1997 11:33 AM
To:	1394ohci-l@austin.ibm.com
Subject:	timeStamp and xferStatus

After giving some more thought to various questions about timeStamp, I think 
we might be in need of a more subtile way of denoting what is happening.  I 
believe that, in general, we allow the HC to write to xferStatus whenever it 
needs to write a timeStamp and to write a timeStamp whenever it writes the 
xferStatus.  However, an 'incidental' write of xferStatus or timeStamp is not 
required to be 'valid' so software is not allowed to do anything based on the 
value of an 'incidental' field.  I don't know how to accurately represent this 
in a drawing so that it is clear what is 'valid' and what is 'incidental'.

When the HC writes the prefix quadlet to a packet per buffer IR receive 
buffer, the timeStamp is valid and the xferStatus is incidental.  On an AT 
response, when the xferStatus is written to the OUTPUT_LAST_*, the HC may 
'incidentally' write the timeStamp field (this means that SW must generate a 
new timeStamp value if the response packet is resubmitted after the transmit 
fails due to other than a timeout.)  I hope this clarifies this.  If not, let 
be know and we'll try to do better.

David Wooten
From:	carlh@nonno.East.Sun.COM
Sent:	Tuesday, January 14, 1997 12:59 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: timeStamp and xferStatus


Hi,

Section 9.1.5, Output-Last-Quadlet descriptor, what is the
definition of "transmitCycleMark" field?  In table 9-4, there
is a note that transmitCycleMark is described in table 9-3, 
but it is not defined.  Should "transmitCycleMark" be "timestamp"?

Thanks,

- Carl
From:	daisy@sis.com.tw
Sent:	Tuesday, January 14, 1997 5:44 PM
To:	DavidW@bangate.compaq.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	PHY packet

Hi, David,

I can accept the definition of PHY packet this way if SW can easily check
whether the packet is a real PHY packet, thanks for the answer.
Here is another question, I think PHY packet belongs to asynchronous 
packet type, suppose we receive a packet with tocde = "4'ha", which means 
an Isochronous packet, in Isochronous cycle, and we find that it's has 
zero length data payload, header CRC check fail, then we tage the packet 
as a PHY one. But, how can an Asynchronous packet be sent in an Isochronous
cycle ? Don't we send PHY packet by fair arbitration ?   

Regards,

Y.J. Chao

>daisy@sis.com.tw (Yen-Jiuan Chao) Wrote:
>| 
>| Hi, 
>| 
>| I have a question about the answer you replied, you mentioned that, for an
>| Isochronous packet with zero length data and header CRC error will be taged
>| as a PHY packet. Why should we accept a packet if it has header CRC error ?
>| We don't even know the packet header contains the correct information.
>| 
>| Thanks for your time and answer,
>| 
>| Y.J. Chao
>
>We accept this _rare_ case as a PHY packet because all PHY packets fail CRC.  
>PHY packets are protected by sending two quadlets, the second of which is the 
>logical inverse of the first.  Rather than have the link have to do CRC _and_ 
>inverse checking (PHY does inverse checking) we simply assume that any two 
>quadlet long packet that fails is probably a PHY packet and we stuff it in the 
>AR request fifo/buffer.  SW can easily verify that it really is or is not a 
>PHY packet.
>
>Note, PHY packets sent during the selfID phase of the bus are put into the 
>selfID buffer with no checking of the validity of the packet by the link.
>
>
>| 
>| >| 
>| >| Sec 8.6.4 Figure 8-16: third and fourth quadlet of the figure are not 
>| >described 
>| >| in text. Text in fact talks about "a single following quadlet".
>| >
>| >The figure is correct and the text is wrong.  The PHY receive packet is 4 
>| >quadlets long with the first quadlet containing a tcode of 4'hE.  The 
>second 
>| >quadlet contains the PHY quadlet and the third quadlet should contain the 
>| >inverse of the first qualdet (SW should check.)  The last fourth qualdet 
>| >contains the standard trailer quadlet.
>| >
>| >The reason that we don't strip the check quadlet is that any packet that is 
>
>| >one quadlet plus a check quadlet is assumed to be a PHY packet if the CRC 
>does 
>| >not check.  This means that if an isochronous packet is receive with a zero 
>
>| >length data packet and the CRC fails, the link is going to assume that it 
>is a 
>| >PHY packet and put it into the FIFO taged as a PHY packet.
>| >
>| ====================================
>| Yen-Jiuan Chao (Daisy)
>| Design Engineer
>| Basic Technology Group
>| Silicon Integrated Systems Corp.(SiS)
>| Phone  : 886-3-5774922 ext. 4315
>| Fax    : 886-3-5790651
>| E-mail : daisy@sis.com.tw
>| =====================================
>| 
>| 
>
>
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	shchuang@sis.com.tw
Sent:	Tuesday, January 14, 1997 7:21 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Questions/comments on 0.9 OHCI

Hi all,


I have some questions about OHCI0.9:

(1) In Sec 5.8 Table 5-11, about linkEnable it said " When this bit is clear
the Host Controller is logically disconnected from the 1394 bus, no packets
will be received or processed nor will packets be transmitted".  If this bit
is cleared while the Host Controller is transmitting or receiving a packet,
should it be disconnected from the 1394 bus immediately?  Or it can continue
to process until it transmits or receives a packet completely?

(2) Sec 7.1 paragraph 2, it said that " A descriptor block may have either
one single OUTPUT_LAST-Immediate descriptor, or may have one
OUTPUT_MORE-Immediate descriptor followed by zero to six OUTPUT_MORE*
descriptors, followed by one OUTPUT_LAST* descriptor".  I think the
OUTPUT_MORE* and OUTPUT_LAST* should be OUTPUT_MORE and OUTPUT_LAST and it
should be zero to five OUTPUT_MORE descriptors.

(3) For response packets, is there any broadcast response packet on the 1394
bus?


Thanks for your time and answers.



S.H. Chuang

From:	DavidW@bangate.compaq.com
Sent:	Wednesday, January 15, 1997 7:05 AM
To:	carlh@nonno.East.Sun.COM
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Re: timeStamp and xferStatus

carlh@nonno.East.Sun.COM (Carl Humphreys) Wrote:
| 
| 
| Hi,
| 
| Section 9.1.5, Output-Last-Quadlet descriptor, what is the
| definition of "transmitCycleMark" field?  In table 9-4, there
| is a note that transmitCycleMark is described in table 9-3, 
| but it is not defined.  Should "transmitCycleMark" be "timestamp"?

I believe the field labeled "transmitCycleMark" should read "timeStamp".

| 
| Thanks,
| 
| - Carl
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, January 15, 1997 7:05 AM
To:	1394ohci-l@austin.ibm.com
Subject:	fwd: re: PHY packet

Comments By: David Wooten@Desktop@PCPD Hou
Originally To: SMTP@PCPD Hou G1@Servers[<daisy@sis.com.tw>]
Originally From: David Wooten@Desktop@PCPD Hou
Original Date:  1/15/97  9:02 AM
Comments:



-------------------------[Original Message]--------------------------

Yes, PHY sent during fair arbitration unless we get reset.

If we get a packet with a tcode of 4'hA and the header CRC fails, we don't 
assume that it's an isochronous packet.  If the packet length is two quadlets, 
we assume its a PHY packet.  If you want to throw away packets like this that 
occur during the isochronous interval, make sure that you don't throw away any 
valid PHY packets.  We don't think this failed packet type happens much at all 
so being overly conservative and putting them in the AR request buffer for 
validation by SW is not a burden on SW and it insures that we don't lose valid 
PHY packets.

David


daisy@sis.com.tw (Yen-Jiuan Chao) Wrote:
| 
| Hi, David,
| 
| I can accept the definition of PHY packet this way if SW can easily check
| whether the packet is a real PHY packet, thanks for the answer.
| Here is another question, I think PHY packet belongs to asynchronous 
| packet type, suppose we receive a packet with tocde = "4'ha", which means 
| an Isochronous packet, in Isochronous cycle, and we find that it's has 
| zero length data payload, header CRC check fail, then we tage the packet 
| as a PHY one. But, how can an Asynchronous packet be sent in an Isochronous
| cycle ? Don't we send PHY packet by fair arbitration ?   
| 
| Regards,
| 
| Y.J. Chao
| 
| >daisy@sis.com.tw (Yen-Jiuan Chao) Wrote:
| >| 
| >| Hi, 
| >| 
| >| I have a question about the answer you replied, you mentioned that, for 
an
| >| Isochronous packet with zero length data and header CRC error will be 
taged
| >| as a PHY packet. Why should we accept a packet if it has header CRC error 
?
| >| We don't even know the packet header contains the correct information.
| >| 
| >| Thanks for your time and answer,
| >| 
| >| Y.J. Chao
| >
| >We accept this _rare_ case as a PHY packet because all PHY packets fail 
CRC.  
| >PHY packets are protected by sending two quadlets, the second of which is 
the 
| >logical inverse of the first.  Rather than have the link have to do CRC 
_and_ 
| >inverse checking (PHY does inverse checking) we simply assume that any two 
| >quadlet long packet that fails is probably a PHY packet and we stuff it in 
the 
| >AR request fifo/buffer.  SW can easily verify that it really is or is not a 

| >PHY packet.
| >
| >Note, PHY packets sent during the selfID phase of the bus are put into the 
| >selfID buffer with no checking of the validity of the packet by the link.
| >
| >
| >| 
| >| >| 
| >| >| Sec 8.6.4 Figure 8-16: third and fourth quadlet of the figure are not 
| >| >described 
| >| >| in text. Text in fact talks about "a single following quadlet".
| >| >
| >| >The figure is correct and the text is wrong.  The PHY receive packet is 
4 
| >| >quadlets long with the first quadlet containing a tcode of 4'hE.  The 
| >second 
| >| >quadlet contains the PHY quadlet and the third quadlet should contain 
the 
| >| >inverse of the first qualdet (SW should check.)  The last fourth qualdet 

| >| >contains the standard trailer quadlet.
| >| >
| >| >The reason that we don't strip the check quadlet is that any packet that 
is 
| >
| >| >one quadlet plus a check quadlet is assumed to be a PHY packet if the 
CRC 
| >does 
| >| >not check.  This means that if an isochronous packet is receive with a 
zero 
| >
| >| >length data packet and the CRC fails, the link is going to assume that 
it 
| >is a 
| >| >PHY packet and put it into the FIFO taged as a PHY packet.
| >| >
| >| ====================================
| >| Yen-Jiuan Chao (Daisy)
| >| Design Engineer
| >| Basic Technology Group
| >| Silicon Integrated Systems Corp.(SiS)
| >| Phone  : 886-3-5774922 ext. 4315
| >| Fax    : 886-3-5790651
| >| E-mail : daisy@sis.com.tw
| >| =====================================
| >| 
| >| 
| >
| >
| ====================================
| Yen-Jiuan Chao (Daisy)
| Design Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.(SiS)
| Phone  : 886-3-5774922 ext. 4315
| Fax    : 886-3-5790651
| E-mail : daisy@sis.com.tw
| =====================================
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, January 15, 1997 7:18 AM
To:	shchuang@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: The questions about OHCI0.9

Response is below.

David Wooten

shchuang@sis.com.tw (Shiuh-Herng Chuang) Wrote:
| 
| >cmlin@sis.com.tw Wrote:
| >| 
| >| Hi all,
| >| 
| >| I have questions about OHCI0.9:
| >| 
| >| DavidW@bangate.compaq.com (David Wooten) Wrote:
| >| 
| >| >The reason that we don't strip the check quadlet is that any packet
| >| >that is one quadlet plus a check quadlet is assumed to be a PHY packet
| >| >if the CRC does not check.  This means that if an isochronous packet
| >| >is receive with a zero length data packet and the CRC fails, the link
| >| >is going to assume that it is a PHY packet and put it into the FIFO
| >| >taged as a PHY packet.
| >| 
| >| 1.  What packet will be regarded as the PHY packet?  Whether is the
| >|       packet whose size is two quadlets and CRC check is fail regarded
| >|      as a PHY packet, no matter what content in the packet?
| >
| >yes.
| >
| 
| 
| Hi,
| 
| 
|     I have a question about the mail you replied.  Since the PHY packet is
| defined as a two quadlet length packet with failed CRC, should the link
| checks CRC for any incoming packet during the period of bus reset?  Or any
| two quadlet length packet is a selfID packet during that period?  Or no
| matter how long the incoming packet is, the link receives it totally and
| puts it into the selfID buffer?

A PHY packet is not defined as a two quadlet packet with a failed CRC.  What I 
said was that the HC will assume that any packet that is two quadlets long 
that fails CRC will be assumed to be a PHY packet.  Naturally, thinks that we 
know to be PHY packets (e.g., the packets that come in during the selfID 
phase) are placed in the selfID buffer.  If, during the selfID phase, the HC 
receives a two quadlet packet, that packets is going into the selfID buffer 
whether or not the CRC checks.


| 
|     Thanks for your time and answer.
| 
| 
| S.H. Chuang
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, January 15, 1997 7:12 AM
To:	shchuang@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Questions/comments on 0.9 OHCI

Resoponses embedded below.

David Wooten

shchuang@sis.com.tw (Shiuh-Herng Chuang) Wrote:
| 
| Hi all,
| 
| 
| I have some questions about OHCI0.9:
| 
| (1) In Sec 5.8 Table 5-11, about linkEnable it said " When this bit is clear
| the Host Controller is logically disconnected from the 1394 bus, no packets
| will be received or processed nor will packets be transmitted".  If this bit
| is cleared while the Host Controller is transmitting or receiving a packet,
| should it be disconnected from the 1394 bus immediately?  Or it can continue
| to process until it transmits or receives a packet completely?

Stop 'immediately'.  This is not intended to be a subtile control mechanism.

| 
| (2) Sec 7.1 paragraph 2, it said that " A descriptor block may have either
| one single OUTPUT_LAST-Immediate descriptor, or may have one
| OUTPUT_MORE-Immediate descriptor followed by zero to six OUTPUT_MORE*
| descriptors, followed by one OUTPUT_LAST* descriptor".  I think the
| OUTPUT_MORE* and OUTPUT_LAST* should be OUTPUT_MORE and OUTPUT_LAST and it
| should be zero to five OUTPUT_MORE descriptors.

Right, no '*' on the OUTPUT_MORE or OUTPUT_LAST.

| 
| (3) For response packets, is there any broadcast response packet on the 1394
| bus?

I sure hope not.

| 
| 
| Thanks for your time and answers.
| 
| 
| 
| S.H. Chuang
| 
| 
From:	mis@aluxs.micro.lucent.com
Sent:	Wednesday, January 15, 1997 11:52 AM
To:	1394ohci-l@austin.ibm.com
Cc:	mshinkarovsky@lucent.com
Subject:	PhysicalResponse DMA in OHCI 0.9

Hi all,

Question about Physical Response DMA:
What "spd" code does it use when responding to a Physical read* request?
What "rCode"(s) does it use? (See 7.5.2).

Question about sec 7.5.1.4.
Why is PHY packet transmit sub-section included in AT request section? I thought PHY packets were generated by PHY layer and not by HC or SW?

Thanks as always,
Michael Shinkarovsky
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, January 15, 1997 2:31 PM
To:	mis@aluxs.micro.lucent.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: PhysicalResponse DMA in OHCI 0.9

mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| Hi all,
| 
| Question about Physical Response DMA:
| What "spd" code does it use when responding to a Physical read* request?
| What "rCode"(s) does it use? (See 7.5.2).

Speed of response is same as speed of request.

rcode and tcode of the responses are as appropriate for the request.


| 
| Question about sec 7.5.1.4.
| Why is PHY packet transmit sub-section included in AT request section? I 
thought 
| PHY packets were generated by PHY layer and not by HC or SW?

PHY only generates selfID PHY packets.  Other PHY packets can be/are generated 
by higher levels.

| 
| Thanks as always,
| Michael Shinkarovsky
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, January 15, 1997 2:47 PM
To:	shuming@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Re: Question about GUID,BIB,Config_ROM,Expansion ROM

Responses embeded below.

David Wooten


shuming@sis.com.tw Wrote:
| 
| Hi, all,
| 
|   I have some questions about expansion ROM,Config_ROM, 
| Bus_Informatin_Block, GUID.  I appreciate if you will 
| clearify their usage.
| 
| If 1394 OHC is on add-in adapter card, my questions are:
| 
| (1) Expansion ROM contains BIOS and OpenFirmware, 
| GUID should be loaded on a hardware reset, what else should also be 
| initialized at this moment? 

Set all things that the spec says are set by hardware reset.

|        I guess this problem depends on if we need to support 
| bootbility. Am I right?

I don't think the hardware settings have anything to do with bootability.

| 
| (2) If we implement a seperate GUID ROM, what image should be stored 
| in it? Only GUID or whole Bus_Information_Block?  

OpenHCI spec does not require that anything else be read from GUID ROM.  Spec 
also doesn't limit what an implementation might load from the GUID ROM.

| 
| (3) For those 251 quadlets (from 6th to 256th) of Config_ROM
| (or whole 1K size), where
| should they be stored? Does they created by driver, or by 
| firmware and stored in Expansion Rom? Who should map them? Driver or 
| firmware? 

This is not something that is specified by OpenHCI.

|       I guess all these problems depends on if we need to support 
| bootbility. If we do not need bootbility, all can be done by driver.
| Am I right? 

Some people think that the expansion ROM on an add in card will provide the SW 
that will make booting from 1394 possible.  OpenHCI does not, however, specify 
this process.

| 
| (4) 
|   a. If    ( (VersionRegister.GUID_ROM==1)
|       &&   (Serial ROM image stored in seperate Serial ROM))
|      {
|         1,2,3 quadlet of BIB is set by firmware
|         GUID is set by HW                                
|      }
|      Is it correct?
|   b. If    ( (VersionRegister.GUID_ROM==0)
|       &&   (Serial ROM image stored in Serial ROM))
|      {
|         All five BIB is set by firmware                            
|      }
|      Is it correct?
|   c. If    ( (VersionRegister.GUID_ROM==1)
|       &&   (Serial ROM image stored in Expansion ROM))
|      {
|         1,2,3 quadlet of BIB is set by firmware
|         GUID is set by HW                                
|      }
|      Is it correct? If yes, HW need to know the address where it can 
| load the image.
|   d. If    ( (VersionRegister.GUID_ROM==0)
|       &&   (Serial ROM image stored in Expansion ROM))
|      {
|         All five BIB is set by firmware                            
|      }
|      Is it correct?
| 
/| 
| Thank you for your help.
| ***************************************************************
| Shu-Ming Liu                                                 
| Software Engineer                                            
| Software Design Department                                   
| Silicon Integrated Systems Corp.                             
| Phone 886-35-774922 ext 4157                                 
| Fax   886-35-790651                                          
| <mailto> shuming@sis.com.tw                                  
| ***************************************************************
| 
From:	daisy@sis.com.tw
Sent:	Wednesday, January 15, 1997 6:17 PM
To:	1394ohci-l@austin.ibm.com
Subject:	LinkEnable bit

Hi,

I have another question about LinkEnable bit, when considering TX,
when this bit is zero, does this bit only disable the Link, or it
also stop the TX DMAs to put packets into TXFIFO ?

Thanks for your time and answer,

Y.J. Chao

>>
>>Resoponses embedded below.
>>
>>David Wooten
>>
>>shchuang@sis.com.tw (Shiuh-Herng Chuang) Wrote:
>>| 
>>| Hi all,
>>| 
>>| 
>>| I have some questions about OHCI0.9:
>>| 
>>| (1) In Sec 5.8 Table 5-11, about linkEnable it said " When this bit is clear
>>| the Host Controller is logically disconnected from the 1394 bus, no packets
>>| will be received or processed nor will packets be transmitted".  If this bit
>>| is cleared while the Host Controller is transmitting or receiving a packet,
>>| should it be disconnected from the 1394 bus immediately?  Or it can continue
>>| to process until it transmits or receives a packet completely?
>>
>>Stop 'immediately'.  This is not intended to be a subtile control mechanism.
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	cylin@sis.com.tw
Sent:	Wednesday, January 15, 1997 7:30 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Question about CommandPtr.descriptorAddress

Hi, all:

I have both a comment and a question about descriptorAddress defined
in OHCI0.9:

1) Comment:
Table 3-3, descriptorAddress rw should be rwu. CommandPtr.descriptorAddress
should be updated whenever a branch command with valid Z value is 
completed, thus it points to the address exepected when dead condition
occurs.

2) Question:
When the end of the descriptor list is reached and ContextControl.active
is cleared, what does SW expect CommandPtr.descriptorAddress to be? The
address of the start of the (last) descriptor block, or the end of it?

Thanks for your time and answer,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	cylin@sis.com.tw
Sent:	Thursday, January 16, 1997 12:51 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Error handling for IR in packet/buffer mode

Hi, all:

For IR in packet/buffer mode, when overrun or data length mismatch
occurs, since the buffer is still parsable for SW, does HC need to 
discard the remaining data in the receive FIFO?

Thanks for your answer,


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	cmlin@sis.com.tw
Sent:	Thursday, January 16, 1997 3:23 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw
Subject:	The questions about OHCI0.9

Hi all,

I have three questions about OHCI0.9:

1. If only a single FIFO is implemented for all Rx packets, the link 
    side of the FIFO must know how much space for the AR request
    buffer.  If the AR request buffer is over-run in the link side of
    the FIFO, the link layer will retry the AR request packet. In
    OHCI0.9, It seems that software cannot know the event of the 
    AR request buffer over-run.
    My question is that it is necessary to let software know the event
    so it can prepare more AR request buffers for the retried packet.
    If yes, how to do it?

2. From Table 3-4, it tells which tcode values are used in each of
    various DMAs, such as the tcodes of 0, 1, 4, 5, 9, E are used in 
   the AT request DMA and the AR request DMA.
   My question is that if the tcode of a packet prepared by sofware
   for the specific DMA doesn't include in Table 3-4, such as the
   tcode of 2 is prepared for the AT request DMA, is it a tcode 
   error event?

3. In the nodeNumber field in Table 5-13, it saids "If the PHY sets
    the nodeNumber to 63, all link-level transmits are disabled."
   My question is that are all DMA-level transmits also disabled?
   If it is not and a DMA wants to transmit a packet to the disabled
   link layer, what type event will be set in the ack/err code field of
   the ContextControl register?
  

Thanks for your time and answer,


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chi-Ming Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4324
Fax: 886-3-5790651
Email: cmlin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From:	ikegaya@pc.snec.nec.co.jp
Sent:	Thursday, January 16, 1997 3:42 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Subscribe


I have one request.
I would like to Subscribe at "1394ohci-l@austin.ibm.com".


Best Regards,
Mitsuhiro Ikegaya

---------------------------------------------------------
NEC Shizuoka Ltd.  Personal Computer Eng. Div.
 Mitsuhiro Ikegaya   E-Mail  : ikegaya@pc.snec.nec.co.jp 
                     Tel:+81-537-22-8234
                  Fax:+81-537-22-8236
---------------------------------------------------------

From:	shuming@sis.com.tw
Sent:	Friday, January 17, 1997 9:53 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Posted Write Enable

Hi, All,

  I have a question about posted write enable.

  How can we enable posted write when write request the range offset 
of 48'h0001_0000_0000 to 48'hFFFF_FFFF_FFFF? I think there should be 
a method to check if the host controller supports the PostedWriteAddress
register and one bit in HCControl register to enable posted write. Am I right?

  Thanks for your answer.
***************************************************************
Shu-Ming Liu                                                 
Software Engineer                                            
Software Design Department                                   
Silicon Integrated Systems Corp.                             
Phone 886-35-774922 ext 4157                                 
Fax   886-35-790651                                          
<mailto> shuming@sis.com.tw                                  
***************************************************************
From:	DavidW@bangate.compaq.com
Sent:	Friday, January 17, 1997 6:55 AM
To:	daisy@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: LinkEnable bit

Typical way that SW will clear the LinkEnable is through a SW reset.  If SW 
clears LinkEnable at other times, it should make sure that the Tx DMA's are 
stopped first.

David


daisy@sis.com.tw (Yen-Jiuan Chao) Wrote:
| 
| Hi,
| 
| I have another question about LinkEnable bit, when considering TX,
| when this bit is zero, does this bit only disable the Link, or it
| also stop the TX DMAs to put packets into TXFIFO ?
| 
| Thanks for your time and answer,
| 
| Y.J. Chao
| 

| ====================================
| Yen-Jiuan Chao (Daisy)
| Design Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.(SiS)
| Phone  : 886-3-5774922 ext. 4315
| Fax    : 886-3-5790651
| E-mail : daisy@sis.com.tw
| =====================================
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, January 17, 1997 8:13 AM
To:	1394ohci-l@austin.ibm.com
Subject:	fwd: re: Question about CommandPtr.descriptorAddress

Comments By: David Wooten@Desktop@PCPD Hou
Originally To: SMTP@PCPD Hou G1@Servers[<cylin@sis.com.tw>]
Originally From: David Wooten@Desktop@PCPD Hou
Original Date:  1/17/97  10:12 AM
Comments:



-------------------------[Original Message]--------------------------

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, all:
| 
| I have both a comment and a question about descriptorAddress defined
| in OHCI0.9:
| 
| 1) Comment:
| Table 3-3, descriptorAddress rw should be rwu. CommandPtr.descriptorAddress
| should be updated whenever a branch command with valid Z value is 
| completed, thus it points to the address exepected when dead condition
| occurs.

Both desctiptorAddress and Z should be "rwu".

| 
| 2) Question:
| When the end of the descriptor list is reached and ContextControl.active
| is cleared, what does SW expect CommandPtr.descriptorAddress to be? The
| address of the start of the (last) descriptor block, or the end of it?

The spec allows addressPointer to point anywhere within the last descriptor 
block.  It might be convenient if it actually pointed to the location or 
descripto (not the descriptor block but the 16 byte descriptor) that contained 
the Z=0 branch address that caused the context to pause.  This is especially 
useful for iso Tx when one doesn't know if a list ended because of trying to 
take the skip address in the first descriptor of a block or because of trying 
to take a branch in the last descriptor in the block.


| 
| Thanks for your time and answer,
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, January 17, 1997 8:18 AM
To:	cylin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Error handling for IR in packet/buffer mode

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, all:
| 
| For IR in packet/buffer mode, when overrun or data length mismatch
| occurs, since the buffer is still parsable for SW, does HC need to 
| discard the remaining data in the receive FIFO?

System side of the FIFO will not detect either of these errors until the end 
of the packet is taken out of the FIFO so there is nothing left in the FIFO to 
discard.  Note, when link side of FIFO hits the overrun, it places the error 
indicator in the FIFO at that time and then throws away the remainder of the 
data for that packet (i.e., it does not put any more data for that packet into 
the buffer.)

| 
| Thanks for your answer,
| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, January 17, 1997 11:48 AM
To:	cmlin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: The questions about OHCI0.9

cmlin@sis.com.tw Wrote:
| 
| Hi all,
| 
| I have three questions about OHCI0.9:
| 
| 1. If only a single FIFO is implemented for all Rx packets, the link 
|     side of the FIFO must know how much space for the AR request
|     buffer.  If the AR request buffer is over-run in the link side of
|     the FIFO, the link layer will retry the AR request packet. In
|     OHCI0.9, It seems that software cannot know the event of the 
|     AR request buffer over-run.
|     My question is that it is necessary to let software know the event
|     so it can prepare more AR request buffers for the retried packet.
|     If yes, how to do it?

Microsoft and Apple programmers don't think this is  problem.

| 
| 2. From Table 3-4, it tells which tcode values are used in each of
|     various DMAs, such as the tcodes of 0, 1, 4, 5, 9, E are used in 
|    the AT request DMA and the AR request DMA.
|    My question is that if the tcode of a packet prepared by sofware
|    for the specific DMA doesn't include in Table 3-4, such as the
|    tcode of 2 is prepared for the AT request DMA, is it a tcode 
|    error event?

Yes.  Of course, we need to make sure that the contents of Table 3-4 are 
correct so that we are not specifying that the HC reject a valid packet type.

| 
| 3. In the nodeNumber field in Table 5-13, it saids "If the PHY sets
|     the nodeNumber to 63, all link-level transmits are disabled."
|    My question is that are all DMA-level transmits also disabled?
|    If it is not and a DMA wants to transmit a packet to the disabled
|    link layer, what type event will be set in the ack/err code field of
|    the ContextControl register?

The table is isn't quite accurate about this.  After a reset, AT DMA is 
'disabled' but not IT DMA.  For discussion about how AT DMA handles reset, 
read section 7.2.2.1.  SW should not cause AT DMA to restart if nodeNumber 
contains 63.

|   
| 
| Thanks for your time and answer,| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chi-Ming Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4324
| Fax: 886-3-5790651
| Email: cmlin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, January 17, 1997 12:39 PM
To:	shuming@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Posted Write Enable

Currently, there is no enable bit for posted writes.  SW should always know 
what to do if hardware sets IntEvent.postedWriteErr. If hardware does not 
support posted writes, it will never set a IntEvent.postedWriteErr. 

Posted writes are _never_ allowed for addresses above 48'hFFFE_0000_0000.

David Wooten

shuming@sis.com.tw Wrote:
| 
| Hi, All,
| 
|   I have a question about posted write enable.
| 
|   How can we enable posted write when write request the range offset 
| of 48'h0001_0000_0000 to 48'hFFFF_FFFF_FFFF? I think there should be 
| a method to check if the host controller supports the PostedWriteAddress
| register and one bit in HCControl register to enable posted write. Am I 
right?
| 
|   Thanks for your answer.
| ***************************************************************
| Shu-Ming Liu                                                 
| Software Engineer                                            
| Software Design Department                                   
| Silicon Integrated Systems Corp.                             
| Phone 886-35-774922 ext 4157                                 
| Fax   886-35-790651                                          
| <mailto> shuming@sis.com.tw                                  
| ***************************************************************
| 
From:	cmlin@sis.com.tw
Sent:	Monday, January 20, 1997 2:17 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw
Subject:	A question about Physical Requests

Hi all,

I have a question about Physical Requests in OHCI0.9:

  Does the physical request unit support the 64-bit function
in a compare-swap lock request packet to access the CSRs 
implemented in the OHCI?  For example, a 64-bit 
compare-swap lock request packet are used to access both
CSRs of the ChannelsAvailableHi and ChannelsAvailableLo.

Thanks for your time and answer,


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chi-Ming Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4324
Fax: 886-3-5790651
Email: cmlin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From:	DavidW@bangate.compaq.com
Sent:	Monday, January 20, 1997 8:06 AM
To:	cmlin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: A question about Physical Requests

In the specific case of the ChannelsAvailable register, the 1394 specification 
only allows quadlet accesses to these registers.

More interesting case is for physical memory (low 4G.)  I don't know if we 
state what the physical unit supports in low memory.  Given that we have 
64-bit addresses on 1394, one would think that 64-bit lock operations would be 
useful.  I don't think we state what type of lock operations are supported to 
pysical memory.

For things that end up in the AR request buffer, any size/type of lock can be 
supported in SW.

David

cmlin@sis.com.tw Wrote:
| 
| Hi all,
| 
| I have a question about Physical Requests in OHCI0.9:
| 
|   Does the physical request unit support the 64-bit function
| in a compare-swap lock request packet to access the CSRs 
| implemented in the OHCI?  For example, a 64-bit 
| compare-swap lock request packet are used to access both
| CSRs of the ChannelsAvailableHi and ChannelsAvailableLo.
| 
| Thanks for your time and answer,
| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chi-Ming Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4324
| Fax: 886-3-5790651
| Email: cmlin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Monday, January 20, 1997 9:47 AM
To:	1394ohci-l@austin.ibm.com
Subject:	fwd: re: A question about Physical Requests

Comments By: David Wooten@Desktop@PCPD Hou
Originally To: <DavidW@bangate.compaq.com>
Originally Cc: <mshinkarovsky@lucent.com>
Originally From: mis@aluxs.micro.lucent.com (Michael Shinkarovsky)
Original Date:  1/20/97  11:17 AM
Comments:

Michael points out that we do specify that we don't directly support lock 
operations in physical memory.

David

-------------------------[Original Message]--------------------------

David,
Lock transactions are not supported by Physical Request DMA. Sec 12 para a) says so.
Michael Shinkarovsky

> From leew@austin.ibm.com Mon Jan 20 11:36 EST 1997
> To: cmlin@sis.com.tw
> Cc: 1394ohci-l@austin.ibm.com
> From: leew@austin.ibm.com
> Orig-From: DavidW@bangate.compaq.com
> Date: Mon, 20 Jan 97 10:05:34 CST
> X-Priority: 3 (Normal)
> Original-To: <cmlin@sis.com.tw>
> Original-Cc: <1394ohci-l@austin.ibm.com>
> Subject: re: A question about Physical Requests
> Content-Type> : > text> 
> Content-Length: 1257
> 
> In the specific case of the ChannelsAvailable register, the 1394 specification 
> only allows quadlet accesses to these registers.
> 
> More interesting case is for physical memory (low 4G.)  I don't know if we 
> state what the physical unit supports in low memory.  Given that we have 
> 64-bit addresses on 1394, one would think that 64-bit lock operations would be 
> useful.  I don't think we state what type of lock operations are supported to 
> pysical memory.
> 
> For things that end up in the AR request buffer, any size/type of lock can be 
> supported in SW.
> 
> David
> 
> cmlin@sis.com.tw Wrote:
> | 
> | Hi all,
> | 
> | I have a question about Physical Requests in OHCI0.9:
> | 
> |   Does the physical request unit support the 64-bit function
> | in a compare-swap lock request packet to access the CSRs 
> | implemented in the OHCI?  For example, a 64-bit 
> | compare-swap lock request packet are used to access both
> | CSRs of the ChannelsAvailableHi and ChannelsAvailableLo.
> | 
> | Thanks for your time and answer,
> | 
> | 
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | Chi-Ming Lin
> | Design Engineer
> | Basic Technology Group
> | Silicon Intergrated Systems Corp.
> | Tel: 886-3-5774922 x 4324
> | Fax: 886-3-5790651
> | Email: cmlin@sis.com.tw
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | 
> | 
> | 
> | 
> 
> 
From:	Joseph Bennett - PCD ~ [jbennett@pcocd2.intel.com]
Sent:	Monday, January 20, 1997 2:39 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Clarification questions



Some OHCI clarification questions:

1) isoXmitIntEvent/isoRcvIntEvent:  Can software write a '1' to the bits
   in this register to cause and interrupt.  Software can for the intEvent
   register, but it isn't stated whether this also applies to the iso
   interrupt registers.

2) section 3.1.5, second paragraph states that the descriptor address
   will contain a certain value once the run bit is set.  I thought that
   the only time the descriptor address could be read was:
	* after it was written and run = 0.
	* after context goes dead (dead bit 1, active bit 0)

3) PHY packet receive:  I don't think it is stated which context in
   ARDMA receives PHY packets.  The synthesized phy that is generated
   on a bus reset is sent to the request context, so this may imply that
   phy packets go there as well, but...

4) This seems obvious, but the spec doesn't clearly state which AR packets
   are handled by which context.  A 'little table' may be nice:
	Request Context
	    Quadlet Read Request
	    Quadlet Write Request
	    Block Read Request
	    Block Write Request
	    Lock Request
	    Synthesized phy packet
	    'real' Phy packet???

	Response Context
	    Write Response
	    Queadlet Read Response
	    Block Read Response
	    Lock Response
   
   
-- 

--------------------------------------------------------------------------
- Joe Bennett                                             (916) 356-3722 -
- Intel Corporation                            jbennett@pcocd2.intel.com -
--------------------------------------------------------------------------
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, January 21, 1997 7:35 AM
To:	jbennett@pcocd2.intel.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Clarification questions

Joseph Bennett - PCD ~ <jbennett@pcocd2.intel.com> Wrote:
| 
| 
| 
| Some OHCI clarification questions:
| 
| 1) isoXmitIntEvent/isoRcvIntEvent:  Can software write a '1' to the bits
|    in this register to cause and interrupt.  Software can for the intEvent
|    register, but it isn't stated whether this also applies to the iso
|    interrupt registers.

SW can cause an iso interrupt.

| 
| 2) section 3.1.5, second paragraph states that the descriptor address
|    will contain a certain value once the run bit is set.  I thought that
|    the only time the descriptor address could be read was:
| 	* after it was written and run = 0.
| 	* after context goes dead (dead bit 1, active bit 0)

Currently, the spec says that CommandPtr can be read when 
ContextControl.active is '0' and that the value will be the address of the 
next descriptor block to be executed.  Neither of these is quite correct.

SW should not read CommandPtr if the following expression is true:

	run & !dead & (active | wake)

If the expression is false, then CommandPtr can be read.  If SW writes 
CommandPtr and does not set run, then CommandPtr retains the value set by SW.  
If run is set, then CommandPtr might be changed by the HC by the next time 
that a SW read of CommandPtr is valid.  If (run & !dead & !(active | wake)) 
then descriptorAddress will 'refer' to the descriptor block that contains the 
Z = 0 that caused the HC to set active to 0.   If (run & dead) then 
descriptorAddress will point to the descriptor block in which a fatal error 
occurred.  (If the initial Z value is bad, I'm not sure how SW figures this 
out.)


| 
| 3) PHY packet receive:  I don't think it is stated which context in
|    ARDMA receives PHY packets.  The synthesized phy that is generated
|    on a bus reset is sent to the request context, so this may imply that
|    phy packets go there as well, but...

They should go to the AR request context.

| 
| 4) This seems obvious, but the spec doesn't clearly state which AR packets
|    are handled by which context.  A 'little table' may be nice:
| 	Request Context
| 	    Quadlet Read Request
| 	    Quadlet Write Request
| 	    Block Read Request
| 	    Block Write Request
| 	    Lock Request
| 	    Synthesized phy packet
| 	    'real' Phy packet???
| 
| 	Response Context
| 	    Write Response
| 	    Queadlet Read Response
| 	    Block Read Response
| 	    Lock Response
|    

Do I hear you volunteering to generate this table? I thank you and I'm sure 
that Diana thanks you. ;-)

|    
| -- 
| 
| --------------------------------------------------------------------------
| - Joe Bennett                                             (916) 356-3722 -
| - Intel Corporation                            jbennett@pcocd2.intel.com -
| --------------------------------------------------------------------------
| 
From:	klashman@meow.East.Sun.COM
Sent:	Tuesday, January 21, 1997 9:19 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Clarification questions

>From: DavidW@bangate.compaq.com
>
>Joseph Bennett - PCD ~ <jbennett@pcocd2.intel.com> Wrote:
>| 
>| 4) This seems obvious, but the spec doesn't clearly state which AR packets
>|    are handled by which context.  A 'little table' may be nice:
>| 	Request Context
>| 	    Quadlet Read Request
>| 	    Quadlet Write Request
>| 	    Block Read Request
>| 	    Block Write Request
>| 	    Lock Request
>| 	    Synthesized phy packet
>| 	    'real' Phy packet???
>| 
>| 	Response Context
>| 	    Write Response
>| 	    Queadlet Read Response
>| 	    Block Read Response
>| 	    Lock Response
>|    
>
>Do I hear you volunteering to generate this table? I thank you and I'm sure 
>that Diana thanks you. ;-)

Section 3.4 pg 22 has a table with this info (darn - what else can
we assign to Joe?).  I'll add the synthesized pkt to the AR request list.
If I have time I'll add this detail to the relevant sections for .91 to 
make it easier to find, although it may have to wait until .92.

And speaking about rev 0.91, the current plan is that this will be
available by early next week in time for the OHCI workshop.

Diana

From:	mis@aluxs.micro.lucent.com
Sent:	Tuesday, January 21, 1997 1:47 PM
To:	1394ohci-l@austin.ibm.com
Cc:	mshinkarovsky@lucent.com
Subject:	Physical Response DMA retries

Hi all,
Question about AT retries.
Sec 12.4 of OHCI 0.9 states that Physical Response DMA will retry transmits MaxPhysRespRetries times.
What happens if that number is exceeded? Interrupt? Discard this response?

Thank you.

Michael Shinkarovsky		mshinkarovsky@lucent.com
Lucent Technologies		Tel: +1 610 712 2938
Microelectronics Group		Fax: +1 610 712 2820
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, January 22, 1997 7:07 AM
To:	mis@aluxs.micro.lucent.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Physical Response DMA retries

Do you have a preference?

David

mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| Hi all,
| Question about AT retries.
| Sec 12.4 of OHCI 0.9 states that Physical Response DMA will retry transmits 
| MaxPhysRespRetries times.
| What happens if that number is exceeded? Interrupt? Discard this response?
| 
| Thank you.
| 
| Michael Shinkarovsky		mshinkarovsky@lucent.com
| Lucent Technologies		Tel: +1 610 712 2938
| Microelectronics Group		Fax: +1 610 712 2820
| 
From:	mis@aluxs.micro.lucent.com
Sent:	Wednesday, January 22, 1997 7:15 AM
To:	mis@bangate.compaq.com; DavidW@bangate.compaq.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Physical Response DMA retries

DavidW@bangate.compaq.com (David Wooten) wrote:

> Do you have a preference?
> 
> David
> 
> mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
> | 
> | Hi all,
> | Question about AT retries.
> | Sec 12.4 of OHCI 0.9 states that Physical Response DMA will retry transmits 
> | MaxPhysRespRetries times.
> | What happens if that number is exceeded? Interrupt? Discard this response?

From HW point of view, discard is the easiest. From a spec writer point of view I would spec whatever SW would do in this case (SW does get to handle similar requests via AR DMA and send responses via AT Resp DMA).
However, given that SW does not really want to see interrupts from PhysRespDMA, maybe discard is the best.
Any SW opinions?

Michael Shinkarovsky		mshinkarovsky@lucent.com
Lucent Technologies		Tel: +1 610 712 2938
Microelectronics Group		Fax: +1 610 712 2820
From:	PJohansson@aol.com
Sent:	Wednesday, January 22, 1997 8:03 AM
To:	mis@aluxs.micro.lucent.com; mis@bangate.compaq.com; DavidW@bangate.compaq.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: Physical Response DMA retries

In a message dated 97-01-22 10:39:18 EST, mis@aluxs.micro.lucent.com (Michael
Shinkarovsky) writes:

<< From HW point of view, discard is the easiest. From a spec writer point of
view I would spec whatever SW would do in this case (SW does get to handle
similar requests via AR DMA and send responses via AT Resp DMA).
 However, given that SW does not really want to see interrupts from
PhysRespDMA, maybe discard is the best.
 Any SW opinions?
  >>

I think discard is OK. The requester of the read or write transaction will
detect a timeout and take (higher-level) recovery actions. If the OpenHCI
hardware did interrupt with an error status, what could the software do,
anyway? Log the error?

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	DavidW@bangate.compaq.com
Sent:	Wednesday, January 22, 1997 8:15 AM
To:	mis@aluxs.micro.lucent.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Physical Response DMA retries

I can't think of anything that SW needs to do in the case of hitting the retry 
limit.  

When the HC is doing physical DMA, it is acting as a bridge between buses and 
not as a 'controller'.  In giving a device direct access to the system memory, 
we also give it the responsibility of handling any problems that occur as a 
result of those accesses.  So, I'd say that we don't want to add extra 
hardware to 'solve' this problem because I'm not sure that there is any 
hardware that would be meaningful/useful.  Why would our software care if a 
device busied out on a physical memory access, and, more to the point, what 
could our SW do about it (its the device that made the origional request that 
is generating the busy.)

Just to let you know how I feel about this, I had argued that we don't need no 
stinking retry count for physical requests.  If a device asked for something, 
it should make provisions for accepting the response.  If it didn't, and 
generated busy, screw it (I can understand generating busy on a request but 
not on a response).  I think this should have been a part of the origional 
1394 spec because it would have kept people from doing really stupid things 
like not having a response buffer.  But I digress... (I bet Eric thought he 
had heard the last of this ;-)

Back to physical retry expiration.  When it expires, we do what the spec 
currently says, we stop retrying, period.

David


mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| DavidW@bangate.compaq.com (David Wooten) wrote:
| 
| > Do you have a preference?
| > 
| > David
| > 
| > mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| > | 
| > | Hi all,
| > | Question about AT retries.
| > | Sec 12.4 of OHCI 0.9 states that Physical Response DMA will retry 
transmits 
| > | MaxPhysRespRetries times.
| > | What happens if that number is exceeded? Interrupt? Discard this 
response?
| 
| From HW point of view, discard is the easiest. From a spec writer point of 
view 
| I would spec whatever SW would do in this case (SW does get to handle 
similar 
| requests via AR DMA and send responses via AT Resp DMA).
| However, given that SW does not really want to see interrupts from 
PhysRespDMA, 
| maybe discard is the best.
| Any SW opinions?
| 
| Michael Shinkarovsky		mshinkarovsky@lucent.com
| Lucent Technologies		Tel: +1 610 712 2938
| Microelectronics Group		Fax: +1 610 712 2820
| 
| 
| 
| ----- End Included Message -----
| 
| 
From:	Patrick_Yu@el.nec.com
Sent:	Wednesday, January 22, 1997 8:57 AM
To:	mis@bangate.compaq.com; DavidW@bangate.compaq.com; mis@aluxs.micro.lucent.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re[2]: Physical Response DMA retries

Michael,

Though "discard" is perhaps the easiest for hardware, should such event, if 
happened, be made aware through some kind of status bit to the SW hence the 
applications?  Just a thought.  Thanks.

Yours sincerely,
W.S.P. Yu
NEC Electronics Inc.

______________________________ Reply Separator _________________________________
Subject: re: Physical Response DMA retries
Author:  mis@aluxs.micro.lucent.com (Michael Shinkarovsky) at INTERNET
Date:    1/22/97 10:15 AM


DavidW@bangate.compaq.com (David Wooten) wrote:
     
> Do you have a preference?
> 
> David
> 
> mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote: 
> | 
> | Hi all,
> | Question about AT retries.
> | Sec 12.4 of OHCI 0.9 states that Physical Response DMA will retry transmits 
> | MaxPhysRespRetries times.
> | What happens if that number is exceeded? Interrupt? Discard this response?
     
From HW point of view, discard is the easiest. From a spec writer point of view 
I would spec whatever SW would do in this case (SW does get to handle similar 
requests via AR DMA and send responses via AT Resp DMA).
However, given that SW does not really want to see interrupts from PhysRespDMA, 
maybe discard is the best.
Any SW opinions?
     
Michael Shinkarovsky  mshinkarovsky@lucent.com 
Lucent Technologies  Tel: +1 610 712 2938 
Microelectronics Group  Fax: +1 610 712 2820

From:	Eric W. Anderson [ewa@apple.com]
Sent:	Wednesday, January 22, 1997 11:10 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Physical Response DMA retries

>Just to let you know how I feel about this, I had argued that we don't
need
>no stinking retry count for physical requests.  If a device asked for
>something, it should make provisions for accepting the response.  If it
>didn't, and generated busy, screw it (I can understand generating busy on
a
>request but not on a response).  I think this should have been a part of
>the origional 1394 spec because it would have kept people from doing
really
>stupid things like not having a response buffer.  But I digress... (I bet
>Eric thought he had heard the last of this ;-)

No, I know better :-)

I agree that a device should never issue a request if it knows it will
be unable to accept the response.  But that is different from stating
that a device may only issue a request if there is 100% certainty that
it can accept the response.  There can be substantial time between a
request and a response, and a requestor may not have perfect knowledge
of future conditions.  In a balanced, cost-effective system, I believe
that response retries are more cost- and performance-effective than the
more conservative must-succeed approach.

I cannot find anywhere in 0.9 where we state how much time, if any,
elapses between the three kinds of AT retries.  Do we retry immediately,
after a fairness interval, or after some other event or time period?
Whatever it is, we should state it clearly in section 7.3, and maybe 5.4
too.

>Back to physical retry expiration.  When it expires, we do what the spec 
>currently says, we stop retrying, period.

I agree.  If the retries fail, too bad.  SW can't do anything about it.
The requestor will know about the problem and can take action if needed.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------



From:	stevep@lsi.sel.sony.com
Sent:	Wednesday, January 22, 1997 3:13 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Subscribe



I'd like to subscribe to 1394 Open HCI reflector.

Best Regards,

Steve Pham
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Thursday, January 23, 1997 2:29 AM
To:	1394ohci-l; 1394ta
Subject:	The OpenHCI Workshop Next Week

Greetings,

    The workshop will begin at 8:30 next Weds.  On Thursday,
we will conclude around 2 PM.  Please be sure and register
if your are coming (see TA homepage).

   On Wedsnesday morning, we will have presentations 
addressing specific areas of concern you have raised.  On
Weds. afternoon and Thursday we will do what has been called
the "page turner".  Rather than turning pages, we would like
to do the following (in the interest of time):

   1. I would like for you to send me your concerns on each 
       chapter by e-mail.  I will allocate time for each chapter
       accordingly - leaving some time for discussion at the end
       of each chapter's time.  Typos and small errors will be 
       logged but don't require discussion.  Things that are not
       understandable, inadequate or wrong need to be 
       discussed in the broad forum.  
   2. I will take your concerns and put them on foils.
       As we address each chapter, the concerns given by 
       e-mail will be addressed first.  If time permits, after these
       have been addressed, we will open the floor to additional
       requests.   Additional requests will be welcome whether 
       time permits or not.  If we can't get to your concern, we'll 
       either handle it through side discussions, on the reflector,
       call a meeting - whatever.

   Random page turnings go on for days and can be valuable.
Unfortunately, the size of the group imposes some req'd 
disciplines upon us.  All comments are welcome.  We are trying
to come up with an orderly process to address and close out 
all concerns. 

    Best Regards,
    Lee Wilson
From:	Mike Winchell [mikew@spitfire.co.symbios.com]
Sent:	Thursday, January 23, 1997 9:34 AM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe


I would like to subscribe to this reflector.

Also,
I would like to get directions to the January 29, 30 meeting at Cirrus.

Thanks,
*Mike
From:	mis@aluxs.micro.lucent.com
Sent:	Thursday, January 23, 1997 11:11 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Packet formats for CSR reg access

Hi all,
Where in 0.9 spec do I find packet formats for compare/swap req/response addressed to CSR registers?

Thank you,
Michael Shinkarovsky		mshinkarovsky@lucent.com
Lucent Technologies		Tel: +1 610 712 2938
Microelectronics Group		Fax: +1 610 712 2820
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Thursday, January 23, 1997 5:23 AM
To:	1394-sig; 1394ohci-l
Subject:	Attendance at the OpenHCI Conference

Hi,

   There have been a number of questions on who
can attend the OpenHCI conference at Cirrus next 
week.  The TA web site states a stipulation that you 
must have attended one of the previous two conferences.
We will amend this at this time to address concerns that 
have been raised:

   1.  If your company has attended previously and you 
        need to involve more people - that's fine.  Please 
        try to keep an experience base assigned to OpenHCI
        so we don't backtrack issues.
   2.  If you haven't been to previous conferences but really
        want to be an active OpenHCI developer - OK, that's 
        fine too.  We have one request.  If you want to get 
        involved in OpenHCI please be an active and ongoing
        participant.  To be successful at this, we do need some
        consistency of participation.  Please review the document.

DOCUMENT ACCESS:  The OpenHCI document is at 
ftp://www.austin.ibm.com/pub/chrptech/1394ohci/ohci090.pdf.
Please note that this is an FTP site - not an http site.  I've had
reports that if you go to it as an http site you'll get a messed 
up download from some web explorers.  Please review this 
document if you are coming to the workshop.

LAST REQUEST:  If you are going to attend the conference
please register on the TA home page so that we have an
accurate head count.  This is key so we have enough catering
etc.

  Best Regards,
  Lee Wilson
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Thursday, January 23, 1997 5:29 AM
To:	1394-sig; 1394ohci-l
Subject:	Please Register - Directions

Hi,

     If you haven't registered for the OpenHCI conference
and plan to attend - PLEASE DO SO NOW!!!!!!!!!!!!!!!!!!!!!!
We need an accurate headcount.  Those of you who have
asked to be on the reflector who have also announced
your participation in the workshop will be added to the 
OpenHCI reflector.

     There have also been requests for directions to Cirrus.
All the information you need to register for the conference
and the directions to Cirrus are on the TA web page.

     See you in the Bay area on Weds/Thurs next week.

   Best Regards,
    Lee 
From:	Eric W. Anderson [ewa@apple.com]
Sent:	Thursday, January 23, 1997 12:22 PM
To:	1394ohci-l@austin.ibm.com; Michael Shinkarovsky
Subject:	Re: Packet formats for CSR reg access

>Hi all,
>Where in 0.9 spec do I find packet formats for compare/swap req/response
>addressed to CSR registers?
>
>Thank you,
>Michael Shinkarovsky		mshinkarovsky@lucent.com
>Lucent Technologies		Tel: +1 610 712 2938
>Microelectronics Group		Fax: +1 610 712 2820

I assume you are interested in compare-swap requests addressed to
CSR registers other than those handled in hardware by OpenHCI.  The
requests that end up in the AR DMA are just normal 1394 lock requests,
as shown in OHCI 0.9 figure 8-13.  When software forms a response
packet, it should look like figure 7-17.

Requests handled in hardware by OpenHCI never appear in host memory,
so the only way to describe the format of those packets is as given
in chapter 6 of 1394-1995.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------



From:	wjshieh@sis.com.tw
Sent:	Thursday, January 23, 1997 11:56 PM
To:	leew@austin.ibm.com; 1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw
Subject:	a question about the DMA command descriptors

Hi,
  
  I have a question about the DMA command descriptors.

  If the format of the DMA command descriptor is error,
the H.W. should follow the setting of the descriptors 
or follow the normal flow? 
  One case is if the "b" field in OUTPUT_MORE* is set to 
2'b11, should the H.W. take branch or ignore it?
  Another case is in transmit DMA. If the first descriptor
in a descriptor block contains a "key" value of 3'h0 which
should be 3'h2 for asynchronous transmit DMA and 3'h1 for 
isochronous transmit DMA, what should H.W. do? Follow the
setting or ignore it and treat it as 3'h2 for ATDMA, 3'h1
for ITDMA?
  Besides, should the error condition be reported to S.W.
by evt_unknown?

Thanks for your time and answer,
======================================
Whieh-Jen Shieh
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp. (SiS)
Phone  : 886-3-5774922 ext. 4314
Fax    : 886-3-5790651
E-mail : wjshieh@sis.com.tw
======================================

From:	wjshieh@sis.com.tw
Sent:	Friday, January 24, 1997 12:19 AM
To:	leew@austin.ibm.com; 1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw
Subject:	speed of the IT packets

Hi,
  
  I have a question about the speed of the IT packets.
 
  Since the OHCIv0.9 didn't specify the 'spd' field for 
isochonous transmit format, how can H.W. know the speed 
of the isochonous transmit packets?
  The speed of IT packets should be specified somewhere.
 
Thanks for your time and comments,

======================================
Whieh-Jen Shieh
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp. (SiS)
Phone  : 886-3-5774922 ext. 4314
Fax    : 886-3-5790651
E-mail : wjshieh@sis.com.tw
======================================

From:	Joseph Bennett - PCD ~ [jbennett@pcocd2.intel.com]
Sent:	Friday, January 24, 1997 9:08 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: a question about the DMA command descriptors



The OHCI spec specifically doesn't specify what the hardware
should do in these instances because software should never
set up descriptors in error.

The meaning of "unspecified behavior" is just that, unspecified.
Shutting down the context is one method, jumping into la la
land would be another, and ignoring the error would be yet
another.  I believe the only requirement is that
only that particular controller / context has the unspecified
behavior.  Other contexts should not be affected.

Beyond that, it is up to you to choose a behavior that you
feel comfortable implementing.

Joe


% Hi,
%   
%   I have a question about the DMA command descriptors.
% 
%   If the format of the DMA command descriptor is error,
% the H.W. should follow the setting of the descriptors 
% or follow the normal flow? 
%   One case is if the "b" field in OUTPUT_MORE* is set to 
% 2'b11, should the H.W. take branch or ignore it?
%   Another case is in transmit DMA. If the first descriptor
% in a descriptor block contains a "key" value of 3'h0 which
% should be 3'h2 for asynchronous transmit DMA and 3'h1 for 
% isochronous transmit DMA, what should H.W. do? Follow the
% setting or ignore it and treat it as 3'h2 for ATDMA, 3'h1
% for ITDMA?
%   Besides, should the error condition be reported to S.W.
% by evt_unknown?
% 
% Thanks for your time and answer,
% ======================================
% Whieh-Jen Shieh
% Design Engineer
% Basic Technology Group
% Silicon Integrated Systems Corp. (SiS)
% Phone  : 886-3-5774922 ext. 4314
% Fax    : 886-3-5790651
% E-mail : wjshieh@sis.com.tw
% ======================================
% 
% 


-- 

--------------------------------------------------------------------------
- Joe Bennett                                             (916) 356-3722 -
- Intel Corporation                            jbennett@pcocd2.intel.com -
--------------------------------------------------------------------------
From:	mis@aluxs.micro.lucent.com
Sent:	Friday, January 24, 1997 11:00 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Async receive

Hi all,
A question about sec 3.3. 
Para 5 starting with "The limitations and requirements..." suggests a two FIFO scheme for handling AR traffic. From this paragraph it is not clear where Physical requests (both read and write) would go. 
Physical read requests could go into a special FIFO for Physical Response Unit to process. But since this FIFO is not visible to Link layer, how can Ack_Busy be generated.
Also where should Physical Write requests go then?
I realize that details of Physical Req/Resp unit are up to implementor, but I would like to understand ideas that were incorporated into Sec 3.3.

Thank you for your time and see you at the workshop,

Michael Shinkarovsky		mshinkarovsky@lucent.com
Lucent Technologies		Tel: +1 610 712 2938
Microelectronics Group		Fax: +1 610 712 2820
From:	mis@aluxs.micro.lucent.com
Sent:	Friday, January 24, 1997 12:46 PM
To:	1394ohci-l@austin.ibm.com
Subject:	PhysicalRequests

Hi,

Sec 12 para b) states that if the request is not compare-swap to one of CSRs then ack_type_error will be sent. 
Ack_type_error implies that Link layer is sending it. From this I conclude that link layer should be doing the validity checks to know which ack type to send for this request.
Would better wording be "resp_type_error" implying rcode of this type used in response packet that Phys_Response unit could send?

Thank you,

Michael Shinkarovsky		mshinkarovsky@lucent.com
Lucent Technologies		Tel: +1 610 712 2938
Microelectronics Group		Fax: +1 610 712 2820
From:	klashman@meow.East.Sun.COM
Sent:	Friday, January 24, 1997 3:40 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: speed of the IT packets

The .91 version of OpenHCI will specify that the IT speed
will be part of the IT packet format as follows:

         3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
	 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
	+-------------------------+-----+---+-----------+-------+-------+
	|        reserved         | spd |tag|  channel  | tCode |  sy   |
        +-------------------------+-----+---+-----------+-------+-------+
	|         data length           |           reserved            |
	+-------------------------------+-------------------------------+

This also means that IT OUTPUT_MORE-Quadlet is gone and is
replaced by IT OUTPUT_MORE-Immediate with a req_count of 8.

Diana


>From: wjshieh@sis.com.tw (Shieh Whieh-Jen)
>
>Hi,
>  
>  I have a question about the speed of the IT packets.
> 
>  Since the OHCIv0.9 didn't specify the 'spd' field for 
>isochonous transmit format, how can H.W. know the speed 
>of the isochonous transmit packets?
>  The speed of IT packets should be specified somewhere.
> 
>Thanks for your time and comments,
>
>======================================
>Whieh-Jen Shieh
>Design Engineer
>Basic Technology Group
>Silicon Integrated Systems Corp. (SiS)
>Phone  : 886-3-5774922 ext. 4314
>Fax    : 886-3-5790651
>E-mail : wjshieh@sis.com.tw
>======================================
>
>
From:	Suresh D [dsuresh@utopia.hclt.com]
Sent:	Friday, January 24, 1997 9:25 PM
To:	1394ohci-l@austin.ibm.com
Cc:	dsuresh@utopia.hclt.com
Subject:	1394OHCI specification

Hello,

I came to know about your work through the net. My
company is working on developing the HDL models for
the LINK and PHY layers of the Specification. We also
plan to develop the synthesisable cores for the PHY
and LINk layers. 

The OHCI is a very good step taken to standardise the
different interfaces which are not clearly specified by IEEE.

I would like to have an access to the OHCI specifications and
would like to know what should I do to get the specification.

Please advice.

Thanks and bye
Suresh
Manager, HCL Technologies,
#50-53, Greams Road, Madras
600 006, India
phone +91 -44- 827 5866
fax   +91 - 44- 8278969
email dsuresh@hclt.com
From:	PJohansson@aol.com
Sent:	Sunday, January 26, 1997 7:57 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Self ID Packet(s) in OpenHCI

What sort of self ID packet does OpenHCI transmit in response to a bus reset
while HCControl.linkEnable is cleared to zero?

Is the L bit set or clear?

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	PJohansson@aol.com
Sent:	Sunday, January 26, 1997 7:57 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Changes to Configuration ROM after Initialization

Clauses 5.5.2 through 5.5.5, inclusive, of OpenHCI draft 0.9 describe
registers that contain, essentially, the first quadlet of configuration ROM
and the four quadlets of the Bus_Info_Block.

I think I understand how these registers should work, particularly with
respect to requirements for the EUI-64, but I believe the documentation may
be incorrect.

In clauses 5.5.2 and 5.5.4, the contents of the fields have a restriction
that they "...must be set by firmware before the HCControl.linkEnable bit is
set."

I think this should read "Must be valid at any time the HCControl.linkEnable
bit is set."

The distinction has to do with how one dynamically updates configuration ROM,
for example to add new unit directories as applications are initialized. I'm
assuming the following scenario:

 1) Software adds the image of the new unit directory into the 1K of
configuration ROM space mapped to host memory.

 2) Software calculates a new rom_crc_value for according to the new,
intended length of crc_length in the first quadlet of configuration ROM (this
covers the new directory).

 3) Software clears HCControl.linkEnable

 4) Software updates the Config ROM Header register (see 5.5.2)

 5) Software sets HCControl.linkEnable

If my conclusions are not what you had in mind, please advise me on the
correct method to update configuration ROM.

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	Kean G. Kuiper (8-678-4518) [kgkuiper@VNET.IBM.COM]
Sent:	Monday, January 27, 1997 5:52 AM
To:	1394ohci-l@austin.ibm.com

unsubscribe
From:	DavidW@bangate.compaq.com
Sent:	Monday, January 27, 1997 7:07 AM
To:	mis@aluxs.micro.lucent.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Packet formats for CSR reg access

These formats are in the 1394 specification.

David

mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| Hi all,
| Where in 0.9 spec do I find packet formats for compare/swap req/response 
| addressed to CSR registers?
| 
| Thank you,
| Michael Shinkarovsky		mshinkarovsky@lucent.com
| Lucent Technologies		Tel: +1 610 712 2938
| Microelectronics Group		Fax: +1 610 712 2820
| 
From:	John Nels Fuller
Sent:	Monday, January 27, 1997 11:27 AM
To:	'PJohansson@aol.com'; '1394ohci-l@austin.ibm.com'
Subject:	RE: Changes to Configuration ROM after Initialization

I believe that the statement in clauses 5.5.2 and 5.5.4 is misleading,
the only field that actually affects the operation of the HC is max_rec.
 The other fields, however, should be valid so that other nodes can use
the information; but 1394 and 1212 allow us a way out by allowing the
info_length field of the Config ROM Header to be set to zero to indicate
that the Config ROM is not ready to be accessed.  Thus, assuming that
max_rec is not changing, the procedure to update the Config ROM would
be:

1. Set info_length in Config ROM header to zero.

2. Add image of new unit directory to Config ROM area

3. Make any changes necessary to the Bus Options register (other than
max_rec).

4. Calculate a new rom_crc_value and perhaps a new crc_length and use
these values to update Config ROM Header and at the same time set
info_length to four to indicate that the Config ROM is again available.

5. Generate a bus reset to notify other nodes of the change in your
config rom.



>-----Original Message-----
>From:	PJohansson@aol.com [SMTP:PJohansson@aol.com]
>Sent:	Sunday, January 26, 1997 7:57 AM
>To:	1394ohci-l@austin.ibm.com
>Subject:	Changes to Configuration ROM after Initialization
>
>Clauses 5.5.2 through 5.5.5, inclusive, of OpenHCI draft 0.9 describe
>registers that contain, essentially, the first quadlet of configuration ROM
>and the four quadlets of the Bus_Info_Block.
>
>I think I understand how these registers should work, particularly with
>respect to requirements for the EUI-64, but I believe the documentation may
>be incorrect.
>
>In clauses 5.5.2 and 5.5.4, the contents of the fields have a restriction
>that they "...must be set by firmware before the HCControl.linkEnable bit is
>set."
>
>I think this should read "Must be valid at any time the HCControl.linkEnable
>bit is set."
>
>The distinction has to do with how one dynamically updates configuration ROM,
>for example to add new unit directories as applications are initialized. I'm
>assuming the following scenario:
>
> 1) Software adds the image of the new unit directory into the 1K of
>configuration ROM space mapped to host memory.
>
> 2) Software calculates a new rom_crc_value for according to the new,
>intended length of crc_length in the first quadlet of configuration ROM (this
>covers the new directory).
>
> 3) Software clears HCControl.linkEnable
>
> 4) Software updates the Config ROM Header register (see 5.5.2)
>
> 5) Software sets HCControl.linkEnable
>
>If my conclusions are not what you had in mind, please advise me on the
>correct method to update configuration ROM.
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>
From:	DavidW@bangate.compaq.com
Sent:	Monday, January 27, 1997 10:26 AM
To:	mis@aluxs.micro.lucent.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: PhysicalRequests

Both ack_type_error and resp_type_error are allowed.

David

mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| Hi,
| 
| Sec 12 para b) states that if the request is not compare-swap to one of CSRs 

| then ack_type_error will be sent. 
| Ack_type_error implies that Link layer is sending it. From this I conclude 
that 
| link layer should be doing the validity checks to know which ack type to 
send 
| for this request.
| Would better wording be "resp_type_error" implying rcode of this type used 
in 
| response packet that Phys_Response unit could send?
| 
| Thank you,
| 
| Michael Shinkarovsky		mshinkarovsky@lucent.com
| Lucent Technologies		Tel: +1 610 712 2938
| Microelectronics Group		Fax: +1 610 712 2820
| 
From:	DavidW@bangate.compaq.com
Sent:	Monday, January 27, 1997 8:27 AM
To:	shchuang@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Question on 0.9 OHCI

Is your question do we allow these registers to be accessed with quadlet read? 
 If so, the answer is yes, however we don't _require_ support of any other 
type of lock access to these registers.  Since no device that uses these 
registers is allowed to issue other than a quadlet read or quadlet 
compare-swap on these addresses, it doesn't make much sense to add hardware to 
support those functions.  I don't believe that it is the responsibility of the 
isochronous resource or bus manager to limit the access types.  It is the 
responsibility of the user of the resource.   However, it's probably safer 
just to design the hardware so that it only accepts quadlet reads or quadlet 
compare-swap operations on these registers and send ack_type_error for 
everything else.

David

shchuang@sis.com.tw (Shiuh-Herng Chuang) Wrote:
| 
| Hi, David:
| 
| 
| I have a question about OHCI0.9:
|  
| In Sec 5.5.1, it said "1394 requires certain 1394 bus management resource
| registers be accessible only via "quadlet read and quadlet
| lock"(compare-and-swap) transactions", but in Sec 12, it said that the
| physical request unit will directly handle compare-swaps to access bus
| management resource registers and other requests will be sent an
| ack_type_error.  Does it mean any lock transactions other than
| compare-and-swap transactions will be sent an ack_type_error?  Will other
| requests except quadlet read requests be sent an ack_type_error?
| 
| Thanks for your time and answer.
|  
|  
| S.H. Chuang
|  
|  
| 
| 
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Monday, January 27, 1997 11:51 AM
To:	1394ohci-l@austin.ibm.com
Subject:	fwd: re: Re: Posted Writes and SBP-2

Comments By: David Wooten@Desktop@PCPD Hou
Originally To: SMTP@PCPD Hou G1@Servers[<PJohansson@aol.com>]
Originally From: David Wooten@Desktop@PCPD Hou
Original Date:  1/27/97  10:37 AM
Comments:



-------------------------[Original Message]--------------------------

Peter,

After thinking about this for a while, I have reached the same conclusion as 
you, OHCI does not do a very good job of describing how it deals with 
ordering.  I don't think that this is a hard problem its just one we haven't 
done.  I think that we 'fix' this by insuring that the status update of an 
descriptor block be a fence operation.  We can store data to memory in any 
order but we can only make it visible to SW in a 1394 consistent manner (we 
must update status in the same order that we provide ack_complete or 
response_complete to the 1394 bus.

I don't think that any of this is a particular issue for the vast majority of 
systems, in the near term.  It will, however, start to become an issue when we 
do split transactions on the host bus.

I'll see what I can dream up as a statement to add to the spec.  Perhaps you 
can give it some thought too?

David




PJohansson@aol.com Wrote:
| 
| David,
| 
| Hmmmm.... conceptually, Figure 1-1 on page 3 of draft 0.9 shows different
| FIFO's for AR request (which would get the SBP-2 status block) and for
| physical write requests. They could be independent. What I was wondering
| about is which characteristics of OpenHCI guarantee that software won't see
| the SBP-2 status block before all of the posted writes have completed.
| 
| I agree with your observations about OpenHCI's responsibility for ordering
| posted operations.
| 
| I'm not so sure that the draft makes it clear what the interrelationships
| between the different FIFO's and functional blocks are.
| 
| For example, the payload of a posted write could be in the hands of the
| physical write DMA logic for its journey across the host bus. Is there some
| requirement that I've misssed that requires all physical writes to complete
| before ANY requests coming in are available to host software?
| 
| Peter
| 
| In a message dated 97-01-24 00:23:30 EST, DavidW@bangate.compaq.com writes:
| 
| << Peter,
|  
|  If one posts a write, one would naturally assume the responsibility of 
|  maintaining ordering that would otherwise be provided by the delayed, split 

|  response.  This should not be much of an issue for OpenHCI as we would 
|  probably always put write requests of all kinds through the same FIFO that
| we 
|  put other requests through.  This has the natural effect of keeping order 
|  among the writes.  If the host system allows split transactions, the host 
|  controller will have to maintain ordering among the writes on the host
| system.
|  
|  BTW, we allow posting for writes to offsets between offsets
| 48'h0001_0000_0000 
|  and 48'hFFFE_FFFF_FFFF and we don't require that the host controller report
| to 
|  SW when it failure to complete these writes (unlike posted writes fo first 
|  4GB.)  Supose we don't impose any ordering constrains on writes to this
| space. 
|   Can we get away with it?  If we can, then we can relax our ordering 
|  constraints so that posted writes to low memory can be reordered and postes 

|  writes to high memory can be reordered but writes to high memory can't pass 

|  posted writes to low memory (they can pass non-posted writes to low 
memory.)
|  
|  David
|  
|  PJohansson@aol.com Wrote:
|  | 
|  | These things get a little awkward as the thread grows, but, "Oh, well..."
|  | 
|  | IF posted writes are implemented is there any guarantee of a time within
|  | which they will flow through to system memory? Or is there ANY ordering
|  | relationship between posted writes and other transactions that may arrive
| at
|  | the HCI?
|  | 
|  | I'm thinking of SBP-2 status, which I expect to be a write to CSR space
| (in
|  | order to generate an interrupt and permit the status block to be parsed
| from
|  | the AR queue). If an HCI has been doing posted writes, the SBP-2 target
| may
|  | send the status block as soon as the last ACK_COMPLETE is received. An
|  | example is the case of a disk READ command.
|  | 
|  | The arrival of a status block is a signal to the SBP-2 initiator that
| system
|  | memory has been updated with the data read from disk. If the write
|  | transactions are posted, how is any order relationship preserved between 
|  them
|  | and the write transaction for the status block? The second may be handled
| by
|  | a different FIFO and/or queue, yes? I recognize that the timing window is
|  | small, but is this the only guarantee that events proceed in order?
|  | 
|  | Peter Johansson
|  | 
|  | Congruent Software, Inc.
|  | 3998 Whittle Avenue
|  | Oakland, CA  94602
|  | 
|  | (510) 531-5472
|  | (510) 531-2942 FAX
|  | 
|  | pjohansson@aol.com
|  | 
|  | In a message dated 97-01-22 12:02:22 EST, macomber@thoreau.nsc.com 
(Robert
|  | Macomber) writes:
|  | 
|  | << > 
|  |  > Joe,
|  |  > 
|  |  > I hope you reconsider your decision about the posted write fifo.  A 
one
|  | deep 
|  |  > stack (one posted write at a time) can make a _huge_ difference
|  | performance of 
|  |  > the bus especially with something like SBP.  A two deep stack is right
| at
|  | the 
|  |  > knee.  Difference between none and one is large; between one and two 
is
| 
|  |  > noticeable, and after two, there's no real improvement (unless, of 
|  course,
|  | one 
|  |  > happens to have _really_ large input fifo's in which case, a deeper
| stack
|  | will 
|  |  > help, some.)
|  |  > 
|  |  > David
|  |  
|  |  I was hoping to just say no, too.  It seems to me like the node can get
|  |  good throughput by having multiple outstanding write requests.  With
|  |  such a node it may actually be preferrable to only get write responses
|  |  when the data actually hits the host memory.  Is there something in SBP
|  |  or 1394 that precludes this kind of node?
|  |  
|  |  	- Robert
|  |   >>
|  | 
|  | 
|   >>
| 
| 
From:	Hsin-Yu Chen [hychen@sis.com.tw]
Sent:	Tuesday, January 28, 1997 1:02 AM
To:	1394ohci-l@austin.ibm.com
Subject:	unsubscribe

unsubscribe


Hsin-Yu Chen
Software Design Department
Silicon Integrated System Corp.
Phone : 886-3-5774922 Ext. 4161
Fax   : 886-3-5790651 
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Tuesday, January 28, 1997 5:15 AM
To:	1394ohci-l
Subject:	OHCI091.PDF document

Greetings,

   I have sent the new level of specification to you
as  an attachment on a previous note.  Additionally,
you may find it at 

  ftp://www.austin.ibm.com/pub/chrptech/1394ohci/
        OHCI091.PDF

   See you tomorrow.

   Best Regards,
   Lee
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Tuesday, January 28, 1997 4:53 AM
To:	1394ohci-l
Subject:	.91 OpenHCI Specification

Greetings,

   Please find attached the .91 OpenHCI specification.

   Best Regards,
   Lee Wilson



From:	cylin@sis.com.tw
Sent:	Wednesday, January 29, 1997 5:02 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Changing multiChanMode bit and IRMultiChanMaskHi/Lo

Hi, all:

Sorry to bring this question up this late. I hope someone could 
raise it in the conference. Both OHCI0.9 and 0.91 does not
clearly specify when multiChanMode bit in IR contextControl register
and IRMultiChanMaskHi/Lo can be set/cleared. I suppose they can only 
be changed when contextControl.active is zero, correct?

Thanks for your time and answer,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	joec@lsi.sel.sony.com
Sent:	Wednesday, January 29, 1997 11:44 AM
To:	1394ohci-l@austin.ibm.com


Please put me on this reflector list.


	Thanks...


	Joe Chou
From:	Patrick_Yu@el.nec.com
Sent:	Wednesday, January 29, 1997 1:34 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Comment on Annex B of the 0.91 spec.

     To whom it may concern,
     
     In the PCI implemenation example described in Annex B, there is no 
     mention of which Int_Pin of the 4 PCI INTA/B/C/D# to be used for the 
     Host Controller.  Does that mean the silicon vendors are free to 
     choose any one of these 4 pins?  Please comment.
     
     Perhaps a typo, in section "B.6", there are 2 paragraphs of almost the 
     same descriptions.
     
     Thank you for the attention to this communications.
     
     Yours sincerely,
     W.S.P. Yu
     NEC Electronics Inc.

From:	Rob Lash [Rob_Lash@quickmail.apple.com]
Sent:	Thursday, January 30, 1997 11:55 AM
To:	GATEWAY
Subject:	subscribe

subscribe

Rob Lash
Apple Computer, Inc
One Infinite Loop
Cupertino, CA 95014
email: rob_lash@quickmail.apple.com
voice: 408-974-3889
fax:   408-446-9154

From:	Joseph Bennett - PCD ~ [jbennett@pcocd2.intel.com]
Sent:	Friday, January 31, 1997 7:59 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Comment on Annex B of the 0.91 spec.

%      To whom it may concern,
%      
%      In the PCI implemenation example described in Annex B, there is no 
%      mention of which Int_Pin of the 4 PCI INTA/B/C/D# to be used for the 
%      Host Controller.  Does that mean the silicon vendors are free to 
%      choose any one of these 4 pins?  Please comment.

The int pin is allowed to be any pin, since it is a shared line.  It will
not conflict with any other devices.

%      
%      Perhaps a typo, in section "B.6", there are 2 paragraphs of almost the 
%      same descriptions.
%      
%      Thank you for the attention to this communications.
%      
%      Yours sincerely,
%      W.S.P. Yu
%      NEC Electronics Inc.
% 
% 


-- 

--------------------------------------------------------------------------
- Joe Bennett                                             (916) 356-3722 -
- Intel Corporation                            jbennett@pcocd2.intel.com -
--------------------------------------------------------------------------
From:	Richard Baker [artb@msg.tx.slr.com]
Sent:	Friday, January 31, 1997 2:12 PM
To:	1394ohci-l@austin.ibm.com
Subject:	[Fwd: Re: Comment on Annex B of the 0.91 spec.]

I believe that for a basic PCI-hosted OHCI controller (i.e. a single
function device), the PCI 2.1 spec requires that only INTA# be used.
This is the configuration assumed in Annex B.

If one were implementing a "Multi-function" PCI device, then some or all
of the interrupt pins could be used.  The interrupt pins allowed depend
upon how many functions are implemented.  Note that multi-function
devices must provide a PCI Configuration Space for each function.

INTB#, INTC#, INTD# only have meaning for multi-function devices.

See PCI 2.1 spec, paragraph 2.2.6 for the details.

Regards,
 
Richard Baker
512/425-6205
Solectron Texas
Austin, Texas
email: artb@msg.tx.slr.com

Joseph Bennett - wrote:
> 
> %      To whom it may concern,
> %
> %      In the PCI implemenation example described in Annex B, there is no
> %      mention of which Int_Pin of the 4 PCI INTA/B/C/D# to be used for the
> %      Host Controller.  Does that mean the silicon vendors are free to
> %      choose any one of these 4 pins?  Please comment.
> 
> The int pin is allowed to be any pin, since it is a shared line.  It will
> not conflict with any other devices.
> 
> %
> %      Perhaps a typo, in section "B.6", there are 2 paragraphs of almost the
> %      same descriptions.
> %
> %      Thank you for the attention to this communications.
> %
> %      Yours sincerely,
> %      W.S.P. Yu
> %      NEC Electronics Inc.
> %
> %
> 
> --
> 
> --------------------------------------------------------------------------
> - Joe Bennett                                             (916) 356-3722 -
> - Intel Corporation                            jbennett@pcocd2.intel.com -
> --------------------------------------------------------------------------
From:	sganjooi@central.fmi.fujitsu.com
Sent:	Friday, January 31, 1997 4:20 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Multiple OHCI plugged into the same host


Hi all,

Does 1394 OHCI support multiple
OHCI devices connected to the same
host ?  

If Yes, does both OHCI devices are
enable to communicate with host via
The DMA engines ?



Thanks
Sean Ganjooi
From:	Dmitriy Budko [Dmitriy_Budko@ccm.fm.intel.com]
Sent:	Friday, January 31, 1997 4:55 PM
To:	leew@austin.ibm.com; 1394ohci-l@austin.ibm.com
Subject:	Re: Multiple OHCI plugged into the same host


Text item: 

The  current revision of the OHCI spec does not say a word about multiple OHCI 
controllers on the same host but it does not have anything to preclude such 
option. Probably, we should put something about it in the chapter 1.

 I doubt that anybody will be able to achieve 800 Mps combined bandwidth for a 
PCI implementation so I am questioning the benefits. In addition 
BIOS/firmware/OS have to support such configuration(s). I see two cases:

1. HCs are on separate/bridged buses
2. HCs are on the same bus.


Dmitriy Budko


Hi all,
     
Does 1394 OHCI support multiple
OHCI devices connected to the same
host ?
     
If Yes, does both OHCI devices are
enable to communicate with host via
The DMA engines ?
     
     
     
Thanks
Sean Ganjooi

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: Multiple OHCI plugged into the same host
To: 1394ohci-l@austin.ibm.com
Message-Id: <9702010020.AA11012@central.fmi.fujitsu.com>
From: sganjooi@central.fmi.fujitsu.com (Sean Ganjooi)
Date: Fri, 31 Jan 97 16:20:23 PST
Received: from mozart.fujitsu.com by central.fmi.fujitsu.com (4.1/SMI-4.1)
     id AA11012; Fri, 31 Jan 97 16:20:23 PST
Received: from central.fmi.fujitsu.com (c6) by fmi.fujitsu.com (4.1/SMI-4.1)
     id AA27688; Fri, 31 Jan 97 16:20:45 PST
Received: from fmi.fujitsu.com (oak.fmi.fujitsu.com [162.35.64.19]) by fujitsuI.
fujitsu.com (8.7.5/8.7.3) with SMTP id QAA14039 for <1394ohci-l@austin.ibm.com>;
 Fri, 31 Jan 1997 16:21:52 -0800 (PST)
Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.11.1]) by net
mail.austin.ibm.com (8.6.12/8.6.11) with SMTP id SAA37116 for <1394ohci-l@austin
.ibm.com>; Fri, 31 Jan 1997 18:22:23 -0600
Received: from netmail.austin.ibm.com by marceau.fm.intel.com (8.8.4/10.0i); Sat
, 1 Feb 1997 00:29:23 GMT
Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by fm
mail.fm.intel.com (8.7.4/8.7.3) with ESMTP id QAA11737; Fri, 31 Jan 1997 16:26:1
9 -0800 (PST)
Return-Path: leew@austin.ibm.com
From:	PJohansson@aol.com
Sent:	Friday, January 31, 1997 6:20 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Posted Writes

When posted writes are either not supported or disabled (the
postedWriteEnable bit in the HCControl register is zero), what acknowledge
code is returned for a write request whose offset address is in the range
0x0001 0000 0000 to 0xFFFE FFFF FFFF, inclusive?

I believe it should be ack_complete, according to the rules in Table 1-2.

Table 1-2 could be more clear in differentiating physical writes from writes
addressed to the address space mentioned above. With respect to the physical
response unit, it's not clear what's meant by "...fully loaded into the
receive buffer." When posted writes are disabled, can write requests
addressed to the first 4 GB of memory be fully loaded into the receive
buffer?

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	PJohansson@aol.com
Sent:	Friday, January 31, 1997 6:20 PM
To:	1394ohci-l@austin.ibm.com
Subject:	max_rec and OpenHCI

Particular OpenHCI implementations may impose limits on the maximum data
payload that may be accommodated in a block write transaction-----limits that
have nothing to do with a requirement for software to enqueue adeqaute AR DMA
buffers.

How does host software interrogate an OpenHCI implementation to determine the
maximum value supported for max_rec?

One possible interpretatation of the specification is that not all values of
max_rec are supported in the Bus Options register described in 5.5.4.
Software could discover, by a process of trial-and-error, the maximum value
supported.

I don't think this is a good solution. For other reasons, I believe OpenHCI
should implement the Bus Options register such that software may store any
values (including those currently reserved by 1394-1995) in this
register----and expect the same values to be visible in configuration ROM
space.

A better approach is to add the max_rec field to the read-only Version
register described in 5.2. Software writers would be advised that setting
max_rec in the Bus Options register to any value larger than max_rec in the
Version register may cause unpredictable results. It might also be
appropriate to report the cycle clock accuracy in the Version register, too.

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	PJohansson@aol.com
Sent:	Friday, January 31, 1997 6:20 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Source Bus ID in Physical Responses

1394-1995 is silent on this matter, so it might be a good thing to emphasize
in section 12 of OpenHCI that:

"The source bus ID in a response packet generated by the physical response
unit shall be equal to the destination bus ID from the original request; note
that this is not necessarily the same as the contents of the busNumber field
in the OpenHCI Node ID register."

I plan to incorporate similar language into P1394a to clarify the
ambiguity----but it won't hurt to make sure it's repeated in an obvious place
in OpenHCI.

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	PJohansson@aol.com
Sent:	Friday, January 31, 1997 6:20 PM
To:	1394ohci-l@austin.ibm.com
Subject:	RESET_START

IEEE Std 1394-1995 is imprecise as to the effects of a write to RESET_START.
Presumably many of the effects could be unit-dependent as well as
node-dependent.

It would help promote interoperability if OpenHCI would specify the expected
results of a write to RESET_START. These results could include, but might not
be limited to effects upon:

   a) the various FIFO's maintained by OpenHCI;
   b) transactions queued within the physical response unit;
   c) OpenHCI registers; and
   d) DMA contexts.

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	PJohansson@aol.com
Sent:	Friday, January 31, 1997 6:59 PM
To:	1394ohci-l@austin.ibm.com
Cc:	Dmitriy_Budko@ccm.fm.intel.com
Subject:	Re: Multiple OHCI plugged into the same host

In a message dated 97-01-31 20:23:05 EST, Dmitriy_Budko@ccm.fm.intel.com
(Dmitriy Budko) writes:

<< The  current revision of the OHCI spec does not say a word about multiple
OHCI 
 controllers on the same host but it does not have anything to preclude such 
 option. Probably, we should put something about it in the chapter 1.
 
  I doubt that anybody will be able to achieve 800 Mps combined bandwidth for
a 
 PCI implementation so I am questioning the benefits. >>

There may be reasons for two OpenHCI in a single system for which bandwidth
is not a problem. For example, if some collection of applications (or,
indeed, some single application) has a need for more than one simultaneous,
multi-channel isochronous DMA context, multiple OpenHCI may be the only
practical solution. It's got to be cheaper than a second computer system...

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

PS By the way, what are we going to call a collection of multiple OpenHCI
installed in one host? A gaggle? A mob? An asylum?


From:	Patrick_Yu@el.nec.com
Sent:	Tuesday, January 28, 1997 8:48 PM
To:	leew@austin.ibm.com; 1394ohci-l@austin.ibm.com; Dmitriy Budko
Subject:	Re[2]: Multiple OHCI plugged into the same host

Dmitriy,

Yes, 1Gbps (net is 800Mbps) will be too much for PCI-32 @ 33MHz to handle, let 
alone multiple OHCI Controllers.  

The fellow silicon developers and the system OEMs should, however, use a little 
bit of common sense whether they independently or collectively decide where to 
put down a single OHCI Controller module.  If the particular HC is expected to 
perform at anything up to 400Mbps, then PCI is still acceptable as far as 
sustained throughput over the host interface is concerned.  Either a add-in card
approach or a standalone motherboard component hanging over the PCI bus will be 
an acceptable installation.  If, however, the intention is to run the HC at 
speed up to 1Gbps, then it would be detrimental to locate this module at 
anywhere other than adjacent to the Controller module for the Memory Sub-system.
 In fact, it truly must be a motherboard component - i.e. an integrated block 
within the Memory Controller.  As such, BIOS/OS should never be a problem to get
the HC behaving appropriately in the system.

Perhaps we also owe much to the industry in terms of using the bandwidth wisely.
And I applaud that Intel has done a good job to promote the "balanced system" 
ever since a few WinHECs ago.

Just my two cents worth of input.  Thank you for the attention to this 
communications.

Yours sincerely,
W.S.P. Yu
Serial Interfaces & Cores
ASIC Strategic Marketing
NEC Electronics Inc.
Santa Clara, CA95050

______________________________ Reply Separator _________________________________
Subject: Re: Multiple OHCI plugged into the same host
Author:  Dmitriy Budko <Dmitriy_Budko@ccm.fm.intel.com> at INTERNET
Date:    1/31/97 4:55 PM


     
Text item: 
     
The  current revision of the OHCI spec does not say a word about multiple OHCI 
controllers on the same host but it does not have anything to preclude such 
option. Probably, we should put something about it in the chapter 1.
     
 I doubt that anybody will be able to achieve 800 Mps combined bandwidth for a 
PCI implementation so I am questioning the benefits. In addition 
BIOS/firmware/OS have to support such configuration(s). I see two cases:
     
1. HCs are on separate/bridged buses 
2. HCs are on the same bus.
     
     
Dmitriy Budko
     
     
Hi all,
     
Does 1394 OHCI support multiple
OHCI devices connected to the same
host ?
     
If Yes, does both OHCI devices are
enable to communicate with host via
The DMA engines ?
     
     
     
Thanks
Sean Ganjooi
     
Text item: External Message Header
     
The following mail header is for administrative use 
and may be ignored unless there are problems.
     
***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
     
Subject: Multiple OHCI plugged into the same host 
To: 1394ohci-l@austin.ibm.com
Message-Id: <9702010020.AA11012@central.fmi.fujitsu.com> 
From: sganjooi@central.fmi.fujitsu.com (Sean Ganjooi) 
Date: Fri, 31 Jan 97 16:20:23 PST
Received: from mozart.fujitsu.com by central.fmi.fujitsu.com (4.1/SMI-4.1)
     id AA11012; Fri, 31 Jan 97 16:20:23 PST
Received: from central.fmi.fujitsu.com (c6) by fmi.fujitsu.com (4.1/SMI-4.1)
     id AA27688; Fri, 31 Jan 97 16:20:45 PST
Received: from fmi.fujitsu.com (oak.fmi.fujitsu.com [162.35.64.19]) by fujitsuI.
fujitsu.com (8.7.5/8.7.3) with SMTP id QAA14039 for <1394ohci-l@austin.ibm.com>;
 Fri, 31 Jan 1997 16:21:52 -0800 (PST)
Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.11.1]) by net
mail.austin.ibm.com (8.6.12/8.6.11) with SMTP id SAA37116 for <1394ohci-l@austin
.ibm.com>; Fri, 31 Jan 1997 18:22:23 -0600
Received: from netmail.austin.ibm.com by marceau.fm.intel.com (8.8.4/10.0i); Sat
, 1 Feb 1997 00:29:23 GMT
Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by fm
mail.fm.intel.com (8.7.4/8.7.3) with ESMTP id QAA11737; Fri, 31 Jan 1997 16:26:1
9 -0800 (PST)
Return-Path: leew@austin.ibm.com

From:	John Nels Fuller
Sent:	Saturday, February 01, 1997 1:24 AM
To:	'leew@austin.ibm.com'; '1394ohci-l@austin.ibm.com'; 'Dmitriy Budko'
Subject:	RE: Multiple OHCI plugged into the same host

The 1394 OpenHCI controller is totally defined to software by the memory
address of it block of registers and by its interrupt, as such the only
requirement necessary to allow multiple controllers on one system is
that the software allow this.  I will stick my neck out and claim that
Microsoft OS's will support multiple copies of the 1394 OpenHCI
controller, but as for BIOSes and other OS's you will need to ask the
appropriate vendors.

>----------
>From: 	Dmitriy Budko[SMTP:Dmitriy_Budko@ccm.fm.intel.com]
>Sent: 	Friday, January 31, 1997 4:55 PM
>To: 	leew@austin.ibm.com; 1394ohci-l@austin.ibm.com
>Subject: 	Re: Multiple OHCI plugged into the same host
>
>
>Text item: 
>
>The  current revision of the OHCI spec does not say a word about multiple
>OHCI 
>controllers on the same host but it does not have anything to preclude such 
>option. Probably, we should put something about it in the chapter 1.
>
> I doubt that anybody will be able to achieve 800 Mps combined bandwidth for
>a 
>PCI implementation so I am questioning the benefits. In addition 
>BIOS/firmware/OS have to support such configuration(s). I see two cases:
>
>1. HCs are on separate/bridged buses
>2. HCs are on the same bus.
>
>
>Dmitriy Budko
>
>
>Hi all,
>     
>Does 1394 OHCI support multiple
>OHCI devices connected to the same
>host ?
>     
>If Yes, does both OHCI devices are
>enable to communicate with host via
>The DMA engines ?
>     
>     
>     
>Thanks
>Sean Ganjooi
>
>Text item: External Message Header
>
>The following mail header is for administrative use
>and may be ignored unless there are problems.
>
>***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
>
>Subject: Multiple OHCI plugged into the same host
>To: 1394ohci-l@austin.ibm.com
>Message-Id: <9702010020.AA11012@central.fmi.fujitsu.com>
>From: sganjooi@central.fmi.fujitsu.com (Sean Ganjooi)
>Date: Fri, 31 Jan 97 16:20:23 PST
>Received: from mozart.fujitsu.com by central.fmi.fujitsu.com (4.1/SMI-4.1)
>     id AA11012; Fri, 31 Jan 97 16:20:23 PST
>Received: from central.fmi.fujitsu.com (c6) by fmi.fujitsu.com (4.1/SMI-4.1)
>     id AA27688; Fri, 31 Jan 97 16:20:45 PST
>Received: from fmi.fujitsu.com (oak.fmi.fujitsu.com [162.35.64.19]) by
>fujitsuI.
>fujitsu.com (8.7.5/8.7.3) with SMTP id QAA14039 for
><1394ohci-l@austin.ibm.com>;
> Fri, 31 Jan 1997 16:21:52 -0800 (PST)
>Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.11.1]) by
>net
>mail.austin.ibm.com (8.6.12/8.6.11) with SMTP id SAA37116 for
><1394ohci-l@austin
>.ibm.com>; Fri, 31 Jan 1997 18:22:23 -0600
>Received: from netmail.austin.ibm.com by marceau.fm.intel.com (8.8.4/10.0i);
>Sat
>, 1 Feb 1997 00:29:23 GMT
>Received: from marceau.fm.intel.com (marceau.fm.intel.com [132.233.247.8]) by
>fm
>mail.fm.intel.com (8.7.4/8.7.3) with ESMTP id QAA11737; Fri, 31 Jan 1997
>16:26:1
>9 -0800 (PST)
>Return-Path: leew@austin.ibm.com
>
From:	Gary A. Hoffman [gary.hoffman@skipstone.com]
Sent:	Saturday, February 01, 1997 4:20 AM
To:	sganjooi@central.fmi.fujitsu.com; 1394ohci-l@austin.ibm.com
Subject:	Re: Multiple OHCI plugged into the same host

Sean,

Right now our software for Windows and Mac support multiple
1394-PCI adapters of the currently available flavors ..
mix and match. The current designs certainly don't do you
any favors in terms of working together, but they do work
under our software control. Needless to say, there are proving
to be applications that require more than one adapter.

I would be unfortunately surprised if there was anything in
the OHCI spec that precluded the use of more than one OHCI
interface in a given system. It would certainly be a business
mistake (to take that backwards step).

gary

At 04:20 PM 1/31/97 PST, Sean Ganjooi wrote:
>
>Hi all,
>
>Does 1394 OHCI support multiple
>OHCI devices connected to the same
>host ?  
>
>If Yes, does both OHCI devices are
>enable to communicate with host via
>The DMA engines ?
>
>
>
>Thanks
>Sean Ganjooi
>

gary a hoffman
Skipstone, CEO
 
512.305.0200 main             Skipstone Is 1394
512.305.0212 fax
gary.hoffman@skipstone.com    3925 West Braker Lane, Suite 425
http://www.skipstone.com      Austin, Texas 78759          USA
From:	John Nels Fuller
Sent:	Saturday, February 01, 1997 7:05 PM
To:	'1394ohci-l@austin.ibm.com'; 'PJohansson@aol.com'
Subject:	RE: Source Bus ID in Physical Responses

Good point, Peter.

Thank you.

jnf

>----------
>From: 	PJohansson@aol.com[SMTP:PJohansson@aol.com]
>Sent: 	Friday, January 31, 1997 6:19 PM
>To: 	1394ohci-l@austin.ibm.com
>Subject: 	Source Bus ID in Physical Responses
>
>1394-1995 is silent on this matter, so it might be a good thing to emphasize
>in section 12 of OpenHCI that:
>
>"The source bus ID in a response packet generated by the physical response
>unit shall be equal to the destination bus ID from the original request; note
>that this is not necessarily the same as the contents of the busNumber field
>in the OpenHCI Node ID register."
>
>I plan to incorporate similar language into P1394a to clarify the
>ambiguity----but it won't hurt to make sure it's repeated in an obvious place
>in OpenHCI.
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>
>
From:	John Nels Fuller
Sent:	Saturday, February 01, 1997 7:05 PM
To:	'1394ohci-l@austin.ibm.com'; 'PJohansson@aol.com'
Subject:	RE: RESET_START

The effects of a RESET_START are to put the packet into the AR request
context (providing it passes the filter).  Overall, the software just
can't handle anyone resetting the HC so we decided to let the software
find an orderly way of doing it.

>----------
>From: 	PJohansson@aol.com[SMTP:PJohansson@aol.com]
>Sent: 	Friday, January 31, 1997 6:20 PM
>To: 	1394ohci-l@austin.ibm.com
>Subject: 	RESET_START
>
>IEEE Std 1394-1995 is imprecise as to the effects of a write to RESET_START.
>Presumably many of the effects could be unit-dependent as well as
>node-dependent.
>
>It would help promote interoperability if OpenHCI would specify the expected
>results of a write to RESET_START. These results could include, but might not
>be limited to effects upon:
>
>   a) the various FIFO's maintained by OpenHCI;
>   b) transactions queued within the physical response unit;
>   c) OpenHCI registers; and
>   d) DMA contexts.
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>
>
From:	John Nels Fuller
Sent:	Saturday, February 01, 1997 7:05 PM
To:	'1394ohci-l@austin.ibm.com'; 'PJohansson@aol.com'
Subject:	RE: max_rec and OpenHCI

It was our intent that the only hardware restrictions on max_rec be
those defined by the maximum size asynchronous packet for the particular
speed of PHY that is used.  It should be possible, for example, to
receive a packet that is larger than the receive FIFO.  To accommodate
this we have specified the recovery mechanisms for FIFO overrun.  When
software sets max_rec it is contracting to provide buffer descriptors in
the AR request context that are at least large enough to receive the
max_rec packet, this will ensure that the hardware will only need to
fetch at most one more Z-block in the middle of the packet.  In fact it
might be desirable for hardware to always try to maintain the next
Z-block pre-fetched so that the fetch doesn't need to be done while the
packet is arriving.

As for the reserved fields in the Bus Options register, you will notice
that they are marked "rw" (read/write) so that they can be used for
specifying as yet undefined options.

>----------
>From: 	PJohansson@aol.com[SMTP:PJohansson@aol.com]
>Sent: 	Friday, January 31, 1997 6:19 PM
>To: 	1394ohci-l@austin.ibm.com
>Subject: 	max_rec and OpenHCI
>
>Particular OpenHCI implementations may impose limits on the maximum data
>payload that may be accommodated in a block write transaction-----limits that
>have nothing to do with a requirement for software to enqueue adeqaute AR DMA
>buffers.
>
>How does host software interrogate an OpenHCI implementation to determine the
>maximum value supported for max_rec?
>
>One possible interpretatation of the specification is that not all values of
>max_rec are supported in the Bus Options register described in 5.5.4.
>Software could discover, by a process of trial-and-error, the maximum value
>supported.
>
>I don't think this is a good solution. For other reasons, I believe OpenHCI
>should implement the Bus Options register such that software may store any
>values (including those currently reserved by 1394-1995) in this
>register----and expect the same values to be visible in configuration ROM
>space.
>
>A better approach is to add the max_rec field to the read-only Version
>register described in 5.2. Software writers would be advised that setting
>max_rec in the Bus Options register to any value larger than max_rec in the
>Version register may cause unpredictable results. It might also be
>appropriate to report the cycle clock accuracy in the Version register, too.
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>
>
From:	PJohansson@aol.com
Sent:	Saturday, February 01, 1997 11:07 PM
To:	1394ohci-l@austin.ibm.com
Cc:	John Nels Fuller
Subject:	Re: RESET_START

In a message dated 97-02-01 22:05:57 EST, jfuller@MICROSOFT.com (John Nels
Fuller) writes:

<< The effects of a RESET_START are to put the packet into the AR request
 context (providing it passes the filter).  Overall, the software just
 can't handle anyone resetting the HC so we decided to let the software
 find an orderly way of doing it.
  >>

Yes----I had forgotten.

But this only pushes the problem back one layer. If the write to RESET_START
passes software's guard dogs, would it be appropriate for OpenHCI to give
some guidelines on the expected behavior of the driver? One of the reasons
the specification is so useful is that it doesn't limit itself to the bare
technical minimum but expounds on good practice.

Just a thought...   :^)

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	PJohansson@aol.com
Sent:	Saturday, February 01, 1997 11:07 PM
To:	John Nels Fuller
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: max_rec and OpenHCI

John et al,

See my comments tucked in below. In general, I incline towards your point of
view but there are some other complications.

In a message dated 97-02-01 22:06:51 EST, jfuller@MICROSOFT.com (John Nels
Fuller) writes:

<< It was our intent that the only hardware restrictions on max_rec be
 those defined by the maximum size asynchronous packet for the particular
 speed of PHY that is used.  It should be possible, for example, to
 receive a packet that is larger than the receive FIFO.  To accommodate
 this we have specified the recovery mechanisms for FIFO overrun.  When
 software sets max_rec it is contracting to provide buffer descriptors in
 the AR request context that are at least large enough to receive the
 max_rec packet, this will ensure that the hardware will only need to
 fetch at most one more Z-block in the middle of the packet.  In fact it
 might be desirable for hardware to always try to maintain the next
 Z-block pre-fetched so that the fetch doesn't need to be done while the
 packet is arriving.>>

This may be your intent and as a software user of OpenHCI it's agreeable to
me, however....

Hardware designers working on OpenHCI might wish to economize on the amount
of memory committed to internal FIFO's. A calculation that involves PCI bus
latency can yield different FIFO sizes dependent upon the maximum payload of
a write request.

Simply put, unless you plan to ban this practice all together, there should
be some way for software to read the biggest size of max_rec that the
particular OpenHCI implementation supports.

As I understand the problem it isn't necessarily related to the number of
Z-blocks enqueued, the size of their buffers or whether or not the OpenHCI
prefetches any Z-blocks. Do you agree?
 
<< As for the reserved fields in the Bus Options register, you will notice
 that they are marked "rw" (read/write) so that they can be used for
 specifying as yet undefined options.
  >>

Glad to hear it! The register contents are not "screened" in any fashion by
OpenHCI.

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	John Nels Fuller
Sent:	Sunday, February 02, 1997 10:50 PM
To:	'PJohansson@aol.com'
Cc:	'1394ohci-l@austin.ibm.com'
Subject:	RE: max_rec and OpenHCI

I think that the actual problem in determining FIFO size will be on
isochronous receive.  Do you think the HW should impose a maximum size
on isochronous packets?  Isochronous gets hard because even if we don't
have huge packets we may need to receive many packets in a row without a
breather.  The net effect is that the HW must be designed so that on
average it keeps up with the rate at which data can come in (e.g.
400MHz) and the FIFO is only used smooth out the rough spots in the HC's
transfer to/from system memory.  I believe that once the isochronous
problem is solved the maximum asynchronous packet size is not an issue.

>----------
>From: 	PJohansson@aol.com[SMTP:PJohansson@aol.com]
>Sent: 	Saturday, February 01, 1997 11:07 PM
>To: 	John Nels Fuller
>Cc: 	1394ohci-l@austin.ibm.com
>Subject: 	Re: max_rec and OpenHCI
>
>John et al,
>
>See my comments tucked in below. In general, I incline towards your point of
>view but there are some other complications.
>
>In a message dated 97-02-01 22:06:51 EST, jfuller@MICROSOFT.com (John Nels
>Fuller) writes:
>
><< It was our intent that the only hardware restrictions on max_rec be
> those defined by the maximum size asynchronous packet for the particular
> speed of PHY that is used.  It should be possible, for example, to
> receive a packet that is larger than the receive FIFO.  To accommodate
> this we have specified the recovery mechanisms for FIFO overrun.  When
> software sets max_rec it is contracting to provide buffer descriptors in
> the AR request context that are at least large enough to receive the
> max_rec packet, this will ensure that the hardware will only need to
> fetch at most one more Z-block in the middle of the packet.  In fact it
> might be desirable for hardware to always try to maintain the next
> Z-block pre-fetched so that the fetch doesn't need to be done while the
> packet is arriving.>>
>
>This may be your intent and as a software user of OpenHCI it's agreeable to
>me, however....
>
>Hardware designers working on OpenHCI might wish to economize on the amount
>of memory committed to internal FIFO's. A calculation that involves PCI bus
>latency can yield different FIFO sizes dependent upon the maximum payload of
>a write request.
>
>Simply put, unless you plan to ban this practice all together, there should
>be some way for software to read the biggest size of max_rec that the
>particular OpenHCI implementation supports.
>
>As I understand the problem it isn't necessarily related to the number of
>Z-blocks enqueued, the size of their buffers or whether or not the OpenHCI
>prefetches any Z-blocks. Do you agree?
> 
><< As for the reserved fields in the Bus Options register, you will notice
> that they are marked "rw" (read/write) so that they can be used for
> specifying as yet undefined options.
>  >>
>
>Glad to hear it! The register contents are not "screened" in any fashion by
>OpenHCI.
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>
>
>
From:	DavidW@bangate.compaq.com
Sent:	Monday, February 03, 1997 9:04 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Re: max_rec and OpenHCI

We might be able to handle this with a simple protocol.  What if the firmware 
initializes max_rec to the maimum value that can be supported by the hardware 
(assuming the attached PHY is running at maxumum speed) and then let SW be  
free to lower this to any other value?

David

PJohansson@aol.com Wrote:
| 
| John et al,
| 
| See my comments tucked in below. In general, I incline towards your point of
| view but there are some other complications.
| 
| In a message dated 97-02-01 22:06:51 EST, jfuller@MICROSOFT.com (John Nels
| Fuller) writes:
| 
| << It was our intent that the only hardware restrictions on max_rec be
|  those defined by the maximum size asynchronous packet for the particular
|  speed of PHY that is used.  It should be possible, for example, to
|  receive a packet that is larger than the receive FIFO.  To accommodate
|  this we have specified the recovery mechanisms for FIFO overrun.  When
|  software sets max_rec it is contracting to provide buffer descriptors in
|  the AR request context that are at least large enough to receive the
|  max_rec packet, this will ensure that the hardware will only need to
|  fetch at most one more Z-block in the middle of the packet.  In fact it
|  might be desirable for hardware to always try to maintain the next
|  Z-block pre-fetched so that the fetch doesn't need to be done while the
|  packet is arriving.>>
| 
| This may be your intent and as a software user of OpenHCI it's agreeable to
| me, however....
| 
| Hardware designers working on OpenHCI might wish to economize on the amount
| of memory committed to internal FIFO's. A calculation that involves PCI bus
| latency can yield different FIFO sizes dependent upon the maximum payload of
| a write request.
| 
| Simply put, unless you plan to ban this practice all together, there should
| be some way for software to read the biggest size of max_rec that the
| particular OpenHCI implementation supports.
| 
| As I understand the problem it isn't necessarily related to the number of
| Z-blocks enqueued, the size of their buffers or whether or not the OpenHCI
| prefetches any Z-blocks. Do you agree?
|  
| << As for the reserved fields in the Bus Options register, you will notice
|  that they are marked "rw" (read/write) so that they can be used for
|  specifying as yet undefined options.
|   >>
| 
| Glad to hear it! The register contents are not "screened" in any fashion by
| OpenHCI.
| 
| Peter Johansson
| 
| Congruent Software, Inc.
| 3998 Whittle Avenue
| Oakland, CA  94602
| 
| (510) 531-5472
| (510) 531-2942 FAX
| 
| pjohansson@aol.com
| 
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Monday, February 03, 1997 8:53 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Re: Multiple OHCI plugged into the same host

There is nothing in the OHCI definition that precludes having multiple OHCI 
controllers in a system.  However, multiple OHCI controllers can not be used 
to create a bridge between two 1394 buses because OHCI does not allow snooping 
or spoofing (two things that a bridge needs.)  That might lessen the value of 
having more than one OHCI controller in a system.

David

"Gary A. Hoffman" <gary.hoffman@skipstone.com> Wrote:
| 
| Sean,
| 
| Right now our software for Windows and Mac support multiple
| 1394-PCI adapters of the currently available flavors ..
| mix and match. The current designs certainly don't do you
| any favors in terms of working together, but they do work
| under our software control. Needless to say, there are proving
| to be applications that require more than one adapter.
| 
| I would be unfortunately surprised if there was anything in
| the OHCI spec that precluded the use of more than one OHCI
| interface in a given system. It would certainly be a business
| mistake (to take that backwards step).
| 
| gary
| 
| At 04:20 PM 1/31/97 PST, Sean Ganjooi wrote:
| >
| >Hi all,
| >
| >Does 1394 OHCI support multiple
| >OHCI devices connected to the same
| >host ?  
| >
| >If Yes, does both OHCI devices are
| >enable to communicate with host via
| >The DMA engines ?
| >
| >
| >
| >Thanks
| >Sean Ganjooi
| >
| 
| gary a hoffman
| Skipstone, CEO
|  
| 512.305.0200 main             Skipstone Is 1394
| 512.305.0212 fax
| gary.hoffman@skipstone.com    3925 West Braker Lane, Suite 425
| http://www.skipstone.com      Austin, Texas 78759          USA
| 
From:	Eric W. Anderson [ewa@apple.com]
Sent:	Monday, February 03, 1997 1:20 PM
To:	John Nels Fuller; '1394ohci-l@austin.ibm.com'
Subject:	RE: Multiple OHCI plugged into the same host

>The 1394 OpenHCI controller is totally defined to software by the memory
>address of it block of registers and by its interrupt, as such the only
>requirement necessary to allow multiple controllers on one system is
>that the software allow this.  I will stick my neck out and claim that
>Microsoft OS's will support multiple copies of the 1394 OpenHCI
>controller, but as for BIOSes and other OS's you will need to ask the
>appropriate vendors.

Thanks for the softball, John :-)

Apple's MacOS architecture for 1394 allows any number of Links in
one system, from one or more vendors.  We've been demonstrating
this since August 96.  OpenHCI should not be a problem.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------



From:	DavidW@bangate.compaq.com
Sent:	Monday, February 03, 1997 8:53 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Re: Multiple OHCI plugged into the same host

There is nothing in the OHCI definition that precludes having multiple OHCI 
controllers in a system.  However, multiple OHCI controllers can not be used 
to create a bridge between two 1394 buses because OHCI does not allow snooping 
or spoofing (two things that a bridge needs.)  That might lessen the value of 
having more than one OHCI controller in a system.

David

"Gary A. Hoffman" <gary.hoffman@skipstone.com> Wrote:
| 
| Sean,
| 
| Right now our software for Windows and Mac support multiple
| 1394-PCI adapters of the currently available flavors ..
| mix and match. The current designs certainly don't do you
| any favors in terms of working together, but they do work
| under our software control. Needless to say, there are proving
| to be applications that require more than one adapter.
| 
| I would be unfortunately surprised if there was anything in
| the OHCI spec that precluded the use of more than one OHCI
| interface in a given system. It would certainly be a business
| mistake (to take that backwards step).
| 
| gary
| 
| At 04:20 PM 1/31/97 PST, Sean Ganjooi wrote:
| >
| >Hi all,
| >
| >Does 1394 OHCI support multiple
| >OHCI devices connected to the same
| >host ?  
| >
| >If Yes, does both OHCI devices are
| >enable to communicate with host via
| >The DMA engines ?
| >
| >
| >
| >Thanks
| >Sean Ganjooi
| >
| 
| gary a hoffman
| Skipstone, CEO
|  
| 512.305.0200 main             Skipstone Is 1394
| 512.305.0212 fax
| gary.hoffman@skipstone.com    3925 West Braker Lane, Suite 425
| http://www.skipstone.com      Austin, Texas 78759          USA
| 
From:	DavidW@bangate.compaq.com
Sent:	Monday, February 03, 1997 11:28 AM
To:	cylin@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Changing multiChanMode bit and IRMultiChanMaskHi/Lo

IRMultiCHanMaskHi and Lo can be changed at any time.  Certain fields of 
ContextControl (bits 28-31) should not be changed unless _run_ is zero (I know 
the spec says that active should be 0 but that's not always enough).

The spec explains when run, active dead and wake bits can be changed.

David

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, all:
| 
| Sorry to bring this question up this late. I hope someone could 
| raise it in the conference. Both OHCI0.9 and 0.91 does not
| clearly specify when multiChanMode bit in IR contextControl register
| and IRMultiChanMaskHi/Lo can be set/cleared. I suppose they can only 
| be changed when contextControl.active is zero, correct?
| 
| Thanks for your time and answer,
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	RichardC@bangate.compaq.com
Sent:	Monday, February 03, 1997 5:50 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Multiple OHCI plugged into the same host

gentlefolk,

And now for an idea that will really set those Intel Architecture Labs teeth 
on edge ... an OHCI or other 800 Mb/s 1394 device located on the AGP bus, in 
the display controller.  As AGP supports peak rates of 533 MB/s, the display 
controller has a fast memory buffer, direct feed of video capture and output 
through the display controller, and the possible attachment of 1394 displays 
directly to the display controller combine to make for some very interesting 
possibilities ... Not that I favor burning very much AGP bandwidth on non-3D 
and other graphics operations ... the idea may be worth examination.


Sincerely,

Richard Churchill,
Adv. Portable PC Arch.,
Compaq Computer Corporation,
P.O. Box 692000, ms120205
Houston, TX, 77269-2000

20555 St. Hwy. 249, ms120205,
Houston, TX, 77070

richardc@bangate.compaq.com
phone: (281)514-6984
fax:   (281)518-5324


PS: Please note that Compaq's Houston phone numbers have changed.  A new
    281 area code has been created for parts of the Houston area, and is
    effective from November 2, 1996.  So, please change all Compaq phone
    numbers you use, or remember the change.  However, the 713 area code
    will continue to work for all Houston Compaq numbers until May 1996.

From:	PJohansson@aol.com
Sent:	Monday, February 03, 1997 9:23 PM
To:	DavidW@bangate.compaq.com; 1394ohci-l@austin.ibm.com
Subject:	Re: max_rec and OpenHCI

In a message dated 97-02-03 15:09:31 EST, DavidW@bangate.compaq.com writes:

<< We might be able to handle this with a simple protocol.  What if the
firmware 
 initializes max_rec to the maimum value that can be supported by the
hardware 
 (assuming the attached PHY is running at maxumum speed) and then let SW be  
 free to lower this to any other value?
  >>

This would work, David, but what if there's no firmware to initialize it? Or
by firmware do you mean "whatever functional block is responsible for getting
the EUI-64 out of a serial PROM and stuffing it into the OPenHCI unique ID
registers before software has a chance to get involved?"

I think the idea of having a read-only field for max_rec in the Version
register is cleaner and simpler. For instance, you don't have to spend any
time explaining when the value is valid and has just been loaded by some
process?

Both would work; the important thing is to have this information
somewehere...

Do you think the same sort of reasoning applies to cycle clock accuracy? I
mean, how is poor old software supposed to know how accurate the oscillator
implemented in the OpenHCI really is?

Peter Johansson
From:	DavidW@bangate.compaq.com
Sent:	Monday, February 03, 1997 11:07 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Posted Writes

Peter,

I didn't see any other response to this so...

HC should always return ack_complete to writes to offsets that are above 
physical memory and not in upper 4GB.  Note, I did not say from 0x0001 0000 
0000 up because Jerry Hauch of Intel wants us to leave room for larger 
physical memory spaces to be accessed by 1394 devices.  He is going to write 
up something for the spec to describe this.  Right Jerry?

David

PJohansson@aol.com Wrote:
| 
| When posted writes are either not supported or disabled (the
| postedWriteEnable bit in the HCControl register is zero), what acknowledge
| code is returned for a write request whose offset address is in the range
| 0x0001 0000 0000 to 0xFFFE FFFF FFFF, inclusive?
| 
| I believe it should be ack_complete, according to the rules in Table 1-2.
| 
| Table 1-2 could be more clear in differentiating physical writes from writes
| addressed to the address space mentioned above. With respect to the physical
| response unit, it's not clear what's meant by "...fully loaded into the
| receive buffer." When posted writes are disabled, can write requests
| addressed to the first 4 GB of memory be fully loaded into the receive
| buffer?
| 
| Peter Johansson
| 
| Congruent Software, Inc.
| 3998 Whittle Avenue
| Oakland, CA  94602
| 
| (510) 531-5472
| (510) 531-2942 FAX
| 
| pjohansson@aol.com
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Monday, February 03, 1997 8:57 AM
To:	shchuang@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	re: Question on 0.91 OHCI

A write that goes to the AR DMA needs to follow the same rules as a write that 
is handled by the physical unit.  If write posting is enabled, then writes to 
40'h0 through 40'h0000_FFFF_FFFF can be posted.  Otherwise, they can not and 
software must provide the response through the AT response unit.  SW will use 
the ack/err field in the trailer quadlet to determine what response is 
required from SW.

Writes to 40'h0001_0000_0000 through 40'hFFFE_FFFF_FFFF can always be posted.

David


shchuang@sis.com.tw (Shiuh-Herng Chuang) Wrote:
| 
| Hi, David:
|  
|  
| I have a question about OHCI0.91:
| 
| In section 12 it describes that if the PostedWriteAddressLo/Hi error
| registers are supported and software has enabled posted writes, write
| requests which are handled by the physical request unit may be posted.  For
| write requests to offsets in the range of 48'h0 to 40'hFFFE_FFFF_FFFF that
| are handled by the AR DMA controller, can they be posted?
| 
| Thanks for your time and answer.
|   
|   
| S.H. Chuang
| 
| 
From:	John Nels Fuller
Sent:	Tuesday, February 04, 1997 9:18 AM
To:	'DavidW@bangate.compaq.com'; 'shchuang@sis.com.tw'
Cc:	'1394ohci-l@austin.ibm.com'
Subject:	RE: Question on 0.91 OHCI

Being the nit picker that I am, I'll just say that all the
40'hxxxx_xxxx_xxxx numbers below should be 48'hxxxx_xxxx_xxxx.

>-----Original Message-----
>From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
>Sent:	Monday, February 03, 1997 8:57 AM
>To:	shchuang@sis.com.tw
>Cc:	1394ohci-l@austin.ibm.com
>Subject:	re: Question on 0.91 OHCI
>
>A write that goes to the AR DMA needs to follow the same rules as a write
>that 
>is handled by the physical unit.  If write posting is enabled, then writes to
>40'h0 through 40'h0000_FFFF_FFFF can be posted.  Otherwise, they can not and 
>software must provide the response through the AT response unit.  SW will use
>the ack/err field in the trailer quadlet to determine what response is 
>required from SW.
>
>Writes to 40'h0001_0000_0000 through 40'hFFFE_FFFF_FFFF can always be posted.
>
>David
>
>
>shchuang@sis.com.tw (Shiuh-Herng Chuang) Wrote:
>| 
>| Hi, David:
>|  
>|  
>| I have a question about OHCI0.91:
>| 
>| In section 12 it describes that if the PostedWriteAddressLo/Hi error
>| registers are supported and software has enabled posted writes, write
>| requests which are handled by the physical request unit may be posted.  For
>| write requests to offsets in the range of 48'h0 to 40'hFFFE_FFFF_FFFF that
>| are handled by the AR DMA controller, can they be posted?
>| 
>| Thanks for your time and answer.
>|   
>|   
>| S.H. Chuang
>| 
>| 
From:	klashman@meow.East.Sun.COM
Sent:	Tuesday, February 04, 1997 10:49 AM
To:	1394ohci-l@austin.ibm.com
Subject:	RE: Multiple OHCI plugged into the same host


>From: "Eric W. Anderson" <ewa@apple.com>
>
>>The 1394 OpenHCI controller is totally defined to software by the memory
>>address of it block of registers and by its interrupt, as such the only
>>requirement necessary to allow multiple controllers on one system is
>>that the software allow this.  I will stick my neck out and claim that
>>Microsoft OS's will support multiple copies of the 1394 OpenHCI
>>controller, but as for BIOSes and other OS's you will need to ask the
>>appropriate vendors.
>
>Thanks for the softball, John :-)
>
>Apple's MacOS architecture for 1394 allows any number of Links in
>one system, from one or more vendors.  We've been demonstrating
>this since August 96.  OpenHCI should not be a problem.
>

This is also true for Solaris (except for the demo part).
Nothing will preclude Solaris from supporting multiple OHCIs.

Diana
From:	mis@aluxs.micro.lucent.com
Sent:	Tuesday, February 04, 1997 11:14 AM
To:	1394ohci-l@austin.ibm.com
Subject:	RE: Source Bus ID in Physical Responses

Under what circumstances will the destination bus ID from original request not equal busNumber field in the OpenHCI NodeID reg of the receiver HC?

Mike

PJohansson@aol.com wrote:

> >1394-1995 is silent on this matter, so it might be a good thing to emphasize
> >in section 12 of OpenHCI that:
> >
> >"The source bus ID in a response packet generated by the physical response
> >unit shall be equal to the destination bus ID from the original request; note
> >that this is not necessarily the same as the contents of the busNumber field
> >in the OpenHCI Node ID register."
> >
> >I plan to incorporate similar language into P1394a to clarify the
> >ambiguity----but it won't hurt to make sure it's repeated in an obvious place
> >in OpenHCI.
> >
> >Peter Johansson


----- End Included Message -----

From:	DavidW@bangate.compaq.com
Sent:	Tuesday, February 04, 1997 8:52 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: RE: Posted Write Enable

Diana points out that I should spend more time reading the spec and less time 
playing Arachnid.  OK, so there is an enable bit. 

IF software supports posted writes, it turns on the postedWriteEnable bit.  If 
hardware doesn't do posted writes, it just never generates a posted write 
error.  There is nothing that needs to be checked to see if the hardware 
supports posted writes.

David

klashman Wrote:
| 
| UNDEFINED 'klashman@meow.East.Sun.COM (Diana Klashman - Sun BOS Software)'
| 
| UNDEFINED
| 
| Page 35 of .91 has this bit in the HCControl reg.
| Diana
| 
| >From leew@austin.ibm.com Mon Feb  3 13:54 EST 1997
| >From: DavidW@bangate.compaq.com
| >To: <hciboys-l@austin.ibm.com>
| >Subject: re: RE: Posted Write Enable
| >
| >I believe we did aggree to add and enable bit but we currently don't have 
one. 
| > I think it would be nice to add one.
| >
| >David
| >
| >John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
| >| 
| >| We did agree during one of our last meetings before the Dec. conference
| >| that there would be a Posted Write Enable bit.
| >| 
| >| >----------
| >| >From: 	DavidW@bangate.compaq.com[SMTP:DavidW@bangate.compaq.com]
| >| >Sent: 	Friday, January 17, 1997 12:38 PM
| >| >To: 	shuming@sis.com.tw
| >| >Cc: 	1394ohci-l@austin.ibm.com
| >| >Subject: 	re: Posted Write Enable
| >| >
| >| >Currently, there is no enable bit for posted writes.  SW should always 
know 
| >
| >| >what to do if hardware sets IntEvent.postedWriteErr. If hardware does 
not 
| >| >support posted writes, it will never set a IntEvent.postedWriteErr. 
| >| >
| >| >Posted writes are _never_ allowed for addresses above 
48'hFFFE_0000_0000.
| >| >
| >| >David Wooten
| >| >
| >| >shuming@sis.com.tw Wrote:
| >| >| 
| >| >| Hi, All,
| >| >| 
| >| >|   I have a question about posted write enable.
| >| >| 
| >| >|   How can we enable posted write when write request the range offset 
| >| >| of 48'h0001_0000_0000 to 48'hFFFF_FFFF_FFFF? I think there should be 
| >| >| a method to check if the host controller supports the 
PostedWriteAddress
| >| >| register and one bit in HCControl register to enable posted write. Am 
I 
| >| >right?
| >| >| 
| >| >|   Thanks for your answer.
| >| >| ***************************************************************
| >| >| Shu-Ming Liu                                                 
| >| >| Software Engineer                                            
| >| >| Software Design Department                                   
| >| >| Silicon Integrated Systems Corp.                             
| >| >| Phone 886-35-774922 ext 4157                                 
| >| >| Fax   886-35-790651                                          
| >| >| <mailto> shuming@sis.com.tw                                  
| >| >| ***************************************************************
| >| >| 
| >| >
| >| 
| >
| 
| 
From:	mis@aluxs.micro.lucent.com
Sent:	Tuesday, February 04, 1997 12:36 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: RE: Posted Write Enable

Please correct me if I am wrong.

It is illegal to do posted writes to range offset above physical memory (range in question). Only Physical Req DMA can do Posted Writes. The address range above physical memory is not to be written by Physical Req DMA.
So the answer should be : one can not enable posted writes to that range.

Mike 

shuming@sis.com.tw Wrote:
> | >| >| 
> | >| >| Hi, All,
> | >| >| 
> | >| >|   I have a question about posted write enable.
> | >| >| 
> | >| >|   How can we enable posted write when write request the range offset 
> | >| >| of 48'h0001_0000_0000 to 48'hFFFF_FFFF_FFFF? I think there should be 
> | >| >| a method to check if the host controller supports the 
> PostedWriteAddress
> | >| >| register and one bit in HCControl register to enable posted write. Am 
> I 
> | >| >right?
> | >| >| 
> | >| >|   Thanks for your answer.
> | >| >| ***************************************************************
> | >| >| Shu-Ming Liu                                                 
> | >| >| Software Engineer                                            
> | >| >| Software Design Department                                   
> | >| >| Silicon Integrated Systems Corp.                             
> | >| >| Phone 886-35-774922 ext 4157                                 
> | >| >| Fax   886-35-790651                                          
> | >| >| <mailto> shuming@sis.com.tw                                  
> | >| >| ***************************************************************
> | >| >| 
> | >| >
> | >| 
> | >
> | 
> | 
> 
> 
From:	klashman@meow.East.Sun.COM
Sent:	Tuesday, February 04, 1997 12:43 PM
To:	1394ohci-l@austin.ibm.com
Subject:	RE: Source Bus ID in Physical Responses


>From: mis@aluxs.micro.lucent.com (Michael Shinkarovsky)
>
>Under what circumstances will the destination bus ID from original request not equal busNumber field in the OpenHCI NodeID reg of the receiver HC?
>
>Mike

Take the case of multiple buses connected together by bridges, in which
each bus has a unique bus ID.  A node on one bus can address another
node on the same bus by using the unique bus ID or by just using 10'h3FF
to indicate the _local_ bus (see 1394-1995 6.2.4.2.1).  Both addresses
are acceptable in that case, but the response should use whatever bus ID
form the request used.  One reason for "mimicking" the bus ID is that it
makes it easier (perhaps necessary) for the requestor to match up responses
with requests (using source & dest Node_IDs & tlabel).

For example, one weird thing you could do is issue two requests to the
same local node with the same tlabel but different bus_IDs, specific and
10'h3FF.  This is possible (if not I'm sure I'll hear about it), but most
assuredly a bad idea.
[Note to Peter J: 1995 6.2.4.3, paragraph 2, line 2 looks like it
should say "node_ID M" rather than "node M".]

Diana


>PJohansson@aol.com wrote:
>
>> >1394-1995 is silent on this matter, so it might be a good thing to emphasize
>> >in section 12 of OpenHCI that:
>> >
>> >"The source bus ID in a response packet generated by the physical response
>> >unit shall be equal to the destination bus ID from the original request; note
>> >that this is not necessarily the same as the contents of the busNumber field
>> >in the OpenHCI Node ID register."
>> >
>> >I plan to incorporate similar language into P1394a to clarify the
>> >ambiguity----but it won't hurt to make sure it's repeated in an obvious place
>> >in OpenHCI.
>> >
>> >Peter Johansson
>
>
>----- End Included Message -----
>
>
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, February 04, 1997 8:52 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: RE: Posted Write Enable

Diana points out that I should spend more time reading the spec and less time 
playing Arachnid.  OK, so there is an enable bit. 

IF software supports posted writes, it turns on the postedWriteEnable bit.  If 
hardware doesn't do posted writes, it just never generates a posted write 
error.  There is nothing that needs to be checked to see if the hardware 
supports posted writes.

David

klashman Wrote:
| 
| UNDEFINED 'klashman@meow.East.Sun.COM (Diana Klashman - Sun BOS Software)'
| 
| UNDEFINED
| 
| Page 35 of .91 has this bit in the HCControl reg.
| Diana
| 
| >From leew@austin.ibm.com Mon Feb  3 13:54 EST 1997
| >From: DavidW@bangate.compaq.com
| >To: <hciboys-l@austin.ibm.com>
| >Subject: re: RE: Posted Write Enable
| >
| >I believe we did aggree to add and enable bit but we currently don't have 
one. 
| > I think it would be nice to add one.
| >
| >David
| >
| >John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
| >| 
| >| We did agree during one of our last meetings before the Dec. conference
| >| that there would be a Posted Write Enable bit.
| >| 
| >| >----------
| >| >From: 	DavidW@bangate.compaq.com[SMTP:DavidW@bangate.compaq.com]
| >| >Sent: 	Friday, January 17, 1997 12:38 PM
| >| >To: 	shuming@sis.com.tw
| >| >Cc: 	1394ohci-l@austin.ibm.com
| >| >Subject: 	re: Posted Write Enable
| >| >
| >| >Currently, there is no enable bit for posted writes.  SW should always 
know 
| >
| >| >what to do if hardware sets IntEvent.postedWriteErr. If hardware does 
not 
| >| >support posted writes, it will never set a IntEvent.postedWriteErr. 
| >| >
| >| >Posted writes are _never_ allowed for addresses above 
48'hFFFE_0000_0000.
| >| >
| >| >David Wooten
| >| >
| >| >shuming@sis.com.tw Wrote:
| >| >| 
| >| >| Hi, All,
| >| >| 
| >| >|   I have a question about posted write enable.
| >| >| 
| >| >|   How can we enable posted write when write request the range offset 
| >| >| of 48'h0001_0000_0000 to 48'hFFFF_FFFF_FFFF? I think there should be 
| >| >| a method to check if the host controller supports the 
PostedWriteAddress
| >| >| register and one bit in HCControl register to enable posted write. Am 
I 
| >| >right?
| >| >| 
| >| >|   Thanks for your answer.
| >| >| ***************************************************************
| >| >| Shu-Ming Liu                                                 
| >| >| Software Engineer                                            
| >| >| Software Design Department                                   
| >| >| Silicon Integrated Systems Corp.                             
| >| >| Phone 886-35-774922 ext 4157                                 
| >| >| Fax   886-35-790651                                          
| >| >| <mailto> shuming@sis.com.tw                                  
| >| >| ***************************************************************
| >| >| 
| >| >
| >| 
| >
| 
| 
From:	sganjooi@central.fmi.fujitsu.com
Sent:	Tuesday, February 04, 1997 2:01 PM
To:	John Nels Fuller; 1394ohci-l@austin.ibm.com; PJohansson@aol.com
Subject:	RE: max_rec and OpenHCI



Hi,
In general, is it safe to prefetch more than one Z block into
the HC ?



In a message dated 97-02-01 22:06:51 EST, jfuller@MICROSOFT.com (John Nels
Fuller) writes:

<< It was our intent that the only hardware restrictions on max_rec be
those defined by the maximum size asynchronous packet for the particular
speed of PHY that is used.  It should be possible, for example, to
receive a packet that is larger than the receive FIFO.  To accommodate
this we have specified the recovery mechanisms for FIFO overrun.  When
software sets max_rec it is contracting to provide buffer descriptors in
the AR request context that are at least large enough to receive the
max_rec packet, this will ensure that the hardware will only need to
fetch at most one more Z-block in the middle of the packet.  In fact it
might be desirable for hardware to always try to maintain the next
Z-block pre-fetched so that the fetch doesn't need to be done while the
packet is arriving. >>



Rergards,
Sean Ganjooi
From:	Eric W. Anderson [ewa@apple.com]
Sent:	Tuesday, February 04, 1997 2:51 PM
To:	Sean Ganjooi; 1394ohci-l@austin.ibm.com
Subject:	RE: max_rec and OpenHCI


>Hi,
>In general, is it safe to prefetch more than one Z block into
>the HC ?
>
>In a message dated 97-02-01 22:06:51 EST, jfuller@MICROSOFT.com (John Nels
>Fuller) writes:
>
><< It was our intent that the only hardware restrictions on max_rec be
>those defined by the maximum size asynchronous packet for the particular
>speed of PHY that is used.  It should be possible, for example, to
>receive a packet that is larger than the receive FIFO.  To accommodate
>this we have specified the recovery mechanisms for FIFO overrun.  When
>software sets max_rec it is contracting to provide buffer descriptors in
>the AR request context that are at least large enough to receive the
>max_rec packet, this will ensure that the hardware will only need to
>fetch at most one more Z-block in the middle of the packet.  In fact it
>might be desirable for hardware to always try to maintain the next
>Z-block pre-fetched so that the fetch doesn't need to be done while the
>packet is arriving. >>
>
>Rergards,
>Sean Ganjooi

OpenHCI 0.91 section 8.1.2 places limits on the modifications that
software may make to AR descriptors that may have been prefetched,
but does not describe how much prefetch there can be.

0.91 section 10.1 states that an IR DMA context program may not be
modified at all while it is running, except to rewrite the branch
address of the final descriptor.  This seems overly restrictive to
me, but it certainly makes most prefetching safe.

I can't find aynthing in 0.91 that gives rules for prefetch on
transmit contexts.

Although I had not expected any implementation to actually prefetch
any more than the current descriptor block (Z block), we should still
give clear guidelines in OpenHCI regarding how much prefetch software
must allow for.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------


From:	DavidW@bangate.compaq.com
Sent:	Tuesday, February 04, 1997 8:39 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Multiple OHCI plugged into the same host

I'd like to ask that architecture discussions of this nature not take place on 
this  reflector.  We'd like to reserve this reflector for dealing with issues 
relating to the OpenHCI specification.

David


RichardC@bangate.compaq.com Wrote:
| 
| gentlefolk,
| 
| And now for an idea that will really set those Intel Architecture Labs teeth 

| on edge ... an OHCI or other 800 Mb/s 1394 device located on the AGP bus, in 

| the display controller.  As AGP supports peak rates of 533 MB/s, the display 

| controller has a fast memory buffer, direct feed of video capture and output 

| through the display controller, and the possible attachment of 1394 displays 

| directly to the display controller combine to make for some very interesting 

| possibilities ... Not that I favor burning very much AGP bandwidth on non-3D 

| and other graphics operations ... the idea may be worth examination.
| 
| 
| Sincerely,
| 
| Richard Churchill,
| Adv. Portable PC Arch.,
| Compaq Computer Corporation,
| P.O. Box 692000, ms120205
| Houston, TX, 77269-2000
| 
| 20555 St. Hwy. 249, ms120205,
| Houston, TX, 77070
| 
| richardc@bangate.compaq.com
| phone: (281)514-6984
| fax:   (281)518-5324
| 
| 
| PS: Please note that Compaq's Houston phone numbers have changed.  A new
|     281 area code has been created for parts of the Houston area, and is
|     effective from November 2, 1996.  So, please change all Compaq phone
|     numbers you use, or remember the change.  However, the 713 area code
|     will continue to work for all Houston Compaq numbers until May 1996.
| 
| 
From:	John Nels Fuller
Sent:	Tuesday, February 04, 1997 11:03 PM
To:	'mis@aluxs.micro.lucent.com'; '1394ohci-l@austin.ibm.com'
Subject:	RE: Source Bus ID in Physical Responses

I can't give any concrete examples, but some notion of being able to use
3FF or the local bus number are being talked about in the bridging
group.  For example, when a broadcast write request is sent to bus 3FF
but the source ID of the sending node indicates the local bus number
this could be taken to mean a global broadcast of the write; whereas, if
the source ID indicates bus 3FF then the broadcast indicates only the
local bus.  Granted a broadcast write request does not generate any
response packets, but nodes may respond to the source ID with a request
of their own, therefore the destination ID in that request would be
identical in bus number to the bus number in the source ID of the
original broadcast.  When this request is responded to by the HC the
proper bus number must be used so that the other end can use it and the
tLabel to match the response to its outstanding request.

The bridging group may decide not to use this scheme, but if we always
respond with the bus number with which we were addressed then any scheme
should work.  Additionally 1394-1995 does not require that nodes use the
bus number instead of 3FF when sending requests.  Nor does 1394-1995 say
that two node IDs that differ in bus number but address the same node
are equivalent, but it does say that a response is uniquely identified
by the source ID, destination ID, and tLabel.  Without a clear statement
that the two flavors of node ID are equivalent, it seems safer to assume
that they are not.

>-----Original Message-----
>From:	mis@aluxs.micro.lucent.com [SMTP:mis@aluxs.micro.lucent.com]
>Sent:	Tuesday, February 04, 1997 11:14 AM
>To:	1394ohci-l@austin.ibm.com
>Subject:	RE: Source Bus ID in Physical Responses
>
>Under what circumstances will the destination bus ID from original request
>not equal busNumber field in the OpenHCI NodeID reg of the receiver HC?
>
>Mike
>
>PJohansson@aol.com wrote:
>
>> >1394-1995 is silent on this matter, so it might be a good thing to
>>emphasize
>> >in section 12 of OpenHCI that:
>> >
>> >"The source bus ID in a response packet generated by the physical response
>> >unit shall be equal to the destination bus ID from the original request;
>>note
>> >that this is not necessarily the same as the contents of the busNumber
>>field
>> >in the OpenHCI Node ID register."
>> >
>> >I plan to incorporate similar language into P1394a to clarify the
>> >ambiguity----but it won't hurt to make sure it's repeated in an obvious
>>place
>> >in OpenHCI.
>> >
>> >Peter Johansson
>
>
>----- End Included Message -----
>
From:	John Nels Fuller
Sent:	Tuesday, February 04, 1997 11:03 PM
To:	'mis@aluxs.micro.lucent.com'; '1394ohci-l@austin.ibm.com'
Subject:	RE: RE: Posted Write Enable

If the Physical DMA filter for a node is off then requests to the
address range corresponding to physical memory are handled by AR request
DMA which in this case can do posted writes.

>-----Original Message-----
>From:	mis@aluxs.micro.lucent.com [SMTP:mis@aluxs.micro.lucent.com]
>Sent:	Tuesday, February 04, 1997 12:36 PM
>To:	1394ohci-l@austin.ibm.com
>Subject:	re: RE: Posted Write Enable
>
>Please correct me if I am wrong.
>
>It is illegal to do posted writes to range offset above physical memory
>(range in question). Only Physical Req DMA can do Posted Writes. The address
>range above physical memory is not to be written by Physical Req DMA.
>So the answer should be : one can not enable posted writes to that range.
>
>Mike 
>
>shuming@sis.com.tw Wrote:
>> | >| >| 
>> | >| >| Hi, All,
>> | >| >| 
>> | >| >|   I have a question about posted write enable.
>> | >| >| 
>> | >| >|   How can we enable posted write when write request the range
>>offset 
>> | >| >| of 48'h0001_0000_0000 to 48'hFFFF_FFFF_FFFF? I think there should
>>be 
>> | >| >| a method to check if the host controller supports the 
>> PostedWriteAddress
>> | >| >| register and one bit in HCControl register to enable posted write.
>>Am 
>> I 
>> | >| >right?
>> | >| >| 
>> | >| >|   Thanks for your answer.
>> | >| >| ***************************************************************
>> | >| >| Shu-Ming Liu                                                 
>> | >| >| Software Engineer                                            
>> | >| >| Software Design Department                                   
>> | >| >| Silicon Integrated Systems Corp.                             
>> | >| >| Phone 886-35-774922 ext 4157                                 
>> | >| >| Fax   886-35-790651                                          
>> | >| >| <mailto> shuming@sis.com.tw                                  
>> | >| >| ***************************************************************
>> | >| >| 
>> | >| >
>> | >| 
>> | >
>> | 
>> | 
>> 
>> 
From:	John Nels Fuller
Sent:	Tuesday, February 04, 1997 11:03 PM
To:	'sganjooi@central.fmi.fujitsu.com'; '1394ohci-l@austin.ibm.com'; 'PJohansson@aol.com'
Subject:	RE: max_rec and OpenHCI

It is safe to prefetch Z-blocks as long as one purges them when the
ContextControl.run bit is turned off.  The software is not allowed to
change anything in a Z-block from the time it is placed on the list
until it is completed (except the branch/skip address when Z==0).

>-----Original Message-----
>From:	sganjooi@central.fmi.fujitsu.com
>[SMTP:sganjooi@central.fmi.fujitsu.com]
>Sent:	Tuesday, February 04, 1997 2:01 PM
>To:	John Nels Fuller; 1394ohci-l@austin.ibm.com; PJohansson@aol.com
>Subject:	RE: max_rec and OpenHCI
>
>
>
>Hi,
>In general, is it safe to prefetch more than one Z block into
>the HC ?
>
>
>
>In a message dated 97-02-01 22:06:51 EST, jfuller@MICROSOFT.com (John Nels
>Fuller) writes:
>
><< It was our intent that the only hardware restrictions on max_rec be
>those defined by the maximum size asynchronous packet for the particular
>speed of PHY that is used.  It should be possible, for example, to
>receive a packet that is larger than the receive FIFO.  To accommodate
>this we have specified the recovery mechanisms for FIFO overrun.  When
>software sets max_rec it is contracting to provide buffer descriptors in
>the AR request context that are at least large enough to receive the
>max_rec packet, this will ensure that the hardware will only need to
>fetch at most one more Z-block in the middle of the packet.  In fact it
>might be desirable for hardware to always try to maintain the next
>Z-block pre-fetched so that the fetch doesn't need to be done while the
>packet is arriving. >>
>
>
>
>Rergards,
>Sean Ganjooi
From:	Lakshminarayanan S [lnarayan@utopia.hclt.com]
Sent:	Tuesday, February 04, 1997 11:02 PM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

subscribe
From:	PJohansson@aol.com
Sent:	Wednesday, February 05, 1997 12:11 AM
To:	mis@aluxs.micro.lucent.com; 1394ohci-l@austin.ibm.com
Subject:	Re: Source Bus ID in Physical Responses

In a message dated 97-02-04 14:54:41 EST, mis@aluxs.micro.lucent.com (Michael
Shinkarovsky) writes:

<< Under what circumstances will the destination bus ID from original request
not equal busNumber field in the OpenHCI NodeID reg of the receiver HC?
  >>

When a Bus Manager (or other intelligence) has specifically enumerated the
bus and assigned a bus ID other than 0x3FF by means of a write to the
NODE_IDS register AND THEN an OpenHCI node originates a request with the
srcBusID bit an asynchronous transmit data clear (i.e., request that the
packet be sent with a source bus ID of 0x3FF).

Peter Johansson

From:	PJohansson@aol.com
Sent:	Wednesday, February 05, 1997 12:11 AM
To:	DavidW@bangate.compaq.com; 1394ohci-l@austin.ibm.com
Subject:	Re: Posted Writes

In a message dated 97-02-04 03:00:19 EST, DavidW@bangate.compaq.com writes:

<< HC should always return ack_complete to writes to offsets that are above 
 physical memory and not in upper 4GB.  Note, I did not say from 0x0001 0000 
 0000 up because Jerry Hauch of Intel wants us to leave room for larger 
 physical memory spaces to be accessed by 1394 devices.  He is going to write

 up something for the spec to describe this.  Right Jerry?
  >>

OK, this is a good clarification. Can the OpenHCI Specification be updated to
eliminate the ambiguity?

Then this leads on to the next question: "How does OpenHCI know where
physical memory ends?" This is important because we're describing two
behaviors, one for physical memory where the posted write enable bit has an
effect and one for "virtual addresses below the CSR's" (or whatever you want
to call it).

If Jerry Hauck is going to be the one to propose a solution, I look forward
to it.

FOR THE TIME BEING, I'm going to assume that writes above 0x0001 0000 0000
and below the CSR's always should return an ack_complete.

Regards,

Peter Johansson

From:	PJohansson@aol.com
Sent:	Wednesday, February 05, 1997 12:11 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Architecture Discussions

For those correspondents just recently booted from this reflector by David
Wooten's request that we not clutter up OpenHCI with the discussions, please
take the conversations to the 1394 TA Architecture reflector,
1394-architecture@1394ta.org.

Sincerely,

Peter Johansson

From:	cmlin@sis.com.tw
Sent:	Wednesday, February 05, 1997 11:52 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw
Subject:	Questions about the posted write

Hi all,

I have two questions about OHCI0.91:

(1)  In section 12.2, paragraph 1, it says " The ack_code sent  for offsets
       in the range of 48'h0001_0000_0000 to 48'hFFFE_FFFF_FFFF when
       not busied is alway ack_complete."  My question is that if an error
       ocurred in writing the posted data packet, whether the host 
       controller sets the IntEvent.postedWriteErr bit or not.  The host
       controller may not implement the posted write functionality.

(2)  In section 12.2, paragraph 2, it says "Write requests to the physical
       memory range of the host may be posted if the host controller 
       supports the PostedWriteAddressLo/Hi error register and software
       has enabled posted writes."  My question is that If a write request 
       is in  the range of 48'h0000_0000_0000 to 48'h0000_FFFF_FFFF 
       but the packet does not pass the physical request filter, whether
       the packet can be posted when the host controller does not
       support the posted write functionality or software has enabled
       posted writes.

Thanks for your time and answer,


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chi-Ming Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4324
Fax: 886-3-5790651
Email: cmlin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From:	mis@aluxs.micro.lucent.com
Sent:	Wednesday, February 05, 1997 9:46 AM
To:	1394ohci-l@austin.ibm.com
Subject:	0.91 notes

Hi all,
Here is a short list of notes against 0.91 OHCI:

1.	Table 8-5 timeStamp field description is different from Table 8-3. 
1a.	xferStatus field in table 8-5 appears to describe xferStatus field in the descriptor (this table describes fields in the data buffer).
1b.	Table 8-3 is a subset of table 8-5. For clarity maybe one table should refer to the other.

2.	Fig 9-10 title: What is "cycleNumber" referring to?

3.	Sec 10.2.2.1: This section implies that s=1, whereas in 10.1 for pkt/buffer mode s= 0 or 1. 

Thank you for your time,

Michael Shinkarovsky		mshinkarovsky@lucent.com
Lucent Technologies		Tel: +1 610 712 2938
Microelectronics Group		Fax: +1 610 712 2820
From:	John Nels Fuller
Sent:	Wednesday, February 05, 1997 11:19 AM
To:	'1394ohci-l@austin.ibm.com'; 'cmlin@sis.com.tw'
Subject:	RE: Questions about the posted write

see below:

>----------
>From: 	cmlin@sis.com.tw[SMTP:cmlin@sis.com.tw]
>Sent: 	Wednesday, February 05, 1997 11:52 AM
>To: 	1394ohci-l@austin.ibm.com
>Cc: 	cmlin@sis.com.tw
>Subject: 	Questions about the posted write
>
>Hi all,
>
>I have two questions about OHCI0.91:
>
>(1)  In section 12.2, paragraph 1, it says " The ack_code sent  for offsets
>       in the range of 48'h0001_0000_0000 to 48'hFFFE_FFFF_FFFF when
>       not busied is alway ack_complete."  My question is that if an error
>       ocurred in writing the posted data packet, whether the host 
>       controller sets the IntEvent.postedWriteErr bit or not.  The host
>       controller may not implement the posted write functionality.

This address range does not require the reporting of postedWriteErr if
the packet cannot be delivered to memory.  Software will use these
addresses for protocols that can handle lost packets.  So the HC may
blindly give an ack_complete for this range even if it does not support
posted writes or if posted writes are not enabled.  To state it another
way, the HC posts the write but pretends that it didn't.

>
>(2)  In section 12.2, paragraph 2, it says "Write requests to the physical
>       memory range of the host may be posted if the host controller 
>       supports the PostedWriteAddressLo/Hi error register and software
>       has enabled posted writes."  My question is that If a write request 
>       is in  the range of 48'h0000_0000_0000 to 48'h0000_FFFF_FFFF 
>       but the packet does not pass the physical request filter, whether
>       the packet can be posted when the host controller does not
>       support the posted write functionality or software has enabled
>       posted writes.

The same rules apply as for physical requests, send ack_pending unless
HC supports PostedWriteAddressLo/Hi for AR requests and software has
enabled posted writes.
Note: it is allowable for a HC to support posted writes for the physical
request unit and not for the AR request context.

>
>Thanks for your time and answer,
>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Chi-Ming Lin
>Design Engineer
>Basic Technology Group
>Silicon Intergrated Systems Corp.
>Tel: 886-3-5774922 x 4324
>Fax: 886-3-5790651
>Email: cmlin@sis.com.tw
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
From:	sganjooi@central.fmi.fujitsu.com
Sent:	Wednesday, February 05, 1997 1:51 PM
To:	1394ohci-l@austin.ibm.com
Subject:	posted writes on physical request


Hi all,

According to section 12.2 of OHCI 0.91 page 116, 4th paragraph, 
"HC is allowed to support any number of posted writes. However, for
each posted write, there must be an error reporting register ....."


If the error reporting register is the postedWriteAddress registers,
there is only one set allocated in table 4-3 pg 24. What address should  the
additional postedWriteAddress registers be located ?



Regards,
Sean Ganjooi

From:	macomber@thoreau.nsc.com
Sent:	Thursday, February 06, 1997 6:03 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: posted writes on physical request

Hi,

> According to section 12.2 of OHCI 0.91 page 116, 4th paragraph, 
> "HC is allowed to support any number of posted writes. However, for
> each posted write, there must be an error reporting register ....."
> 
> 
> If the error reporting register is the postedWriteAddress registers,
> there is only one set allocated in table 4-3 pg 24. What address should  the
> additional postedWriteAddress registers be located ?

The last paragraph of section 12.2 on page 116 describes how this is
done.

	- Robert

-- 
Robert L. Macomber MS 10-26   Phone: (207) 775-4677
National Semiconductor Corp.  Fax:   (207) 761-6108
333 Western Avenue            Email: macomber@thoreau.nsc.com
South Portland, Maine 04106   Advanced Development Center
From:	calvinn@lsi.sel.sony.com
Sent:	Thursday, February 06, 1997 4:55 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Subscribe


	I would like to subscribe to 1394 Open HCI reflector.
From:	DavidW@bangate.compaq.com
Sent:	Friday, February 07, 1997 9:43 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Architecture Discussions

Could we please mover these notices about change of reflectors to another 
reflector.  ;-)

David


PJohansson@aol.com Wrote:
| 
| For those correspondents just recently booted from this reflector by David
| Wooten's request that we not clutter up OpenHCI with the discussions, please
| take the conversations to the 1394 TA Architecture reflector,
| 1394-architecture@1394ta.org.
| 
| Sincerely,
| 
| Peter Johansson
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, February 07, 1997 9:52 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Questions about the posted write

See below.

David

cmlin@sis.com.tw Wrote:
| 
| Hi all,
| 
| I have two questions about OHCI0.91:
| 
| (1)  In section 12.2, paragraph 1, it says " The ack_code sent  for offsets
|        in the range of 48'h0001_0000_0000 to 48'hFFFE_FFFF_FFFF when
|        not busied is alway ack_complete."  My question is that if an error
|        ocurred in writing the posted data packet, whether the host 
|        controller sets the IntEvent.postedWriteErr bit or not.  The host
|        controller may not implement the posted write functionality.

Writes to range of 48'h0001_0000_0000 to 48'hFFFE_FFFF_FFFF are not 'posted.'  
We just send ack_complete.  We only consider the write as 'posted' when it is 
to offsets below 48'h0001_0000_0000.  If error occurs in writing one of these 
non-posted packets to memory, follow the error proceedure for write errors to 
the AR request buffer (I don't have my spec handy so I don't know the section 
-- sorry.)
 
| 
| (2)  In section 12.2, paragraph 2, it says "Write requests to the physical
|        memory range of the host may be posted if the host controller 
|        supports the PostedWriteAddressLo/Hi error register and software
|        has enabled posted writes."  My question is that If a write request 
|        is in  the range of 48'h0000_0000_0000 to 48'h0000_FFFF_FFFF 
|        but the packet does not pass the physical request filter, whether
|        the packet can be posted when the host controller does not
|        support the posted write functionality or software has enabled
|        posted writes.

If the write does not pass the request filter, it is still a write to physical 
space.  One does not have to post these writes but one may post these writes.

| 
| Thanks for your time and answer,
| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chi-Ming Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4324
| Fax: 886-3-5790651
| Email: cmlin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
| 
| 
From:	Eric W. Anderson [ewa@apple.com]
Sent:	Friday, February 07, 1997 10:01 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: RE: max_rec and OpenHCI

Good point.  I forgot that in the ARDMA the Z blocks are small (Z=1),
so it is reasonable to use prefetch.

Eric

>Just wanted to add a small amount to Eric's reply.  For asynch request
>receive using the single FIFO scheme, one will need to prefetch at least
>one Z block so that the link side of the FIFO will know that there is
>space available.
>
>David
>
>"Eric W. Anderson" <ewa@apple.com> Wrote:
>| 
>| 
>| >Hi,
>| >In general, is it safe to prefetch more than one Z block into
>| >the HC ?
>| >
>| >In a message dated 97-02-01 22:06:51 EST, jfuller@MICROSOFT.com (John
>Nels
>| >Fuller) writes:
>| >
>| ><< It was our intent that the only hardware restrictions on max_rec be
>| >those defined by the maximum size asynchronous packet for the
particular
>| >speed of PHY that is used.  It should be possible, for example, to
>| >receive a packet that is larger than the receive FIFO.  To accommodate
>| >this we have specified the recovery mechanisms for FIFO overrun.  When
>| >software sets max_rec it is contracting to provide buffer descriptors
in
>| >the AR request context that are at least large enough to receive the
>| >max_rec packet, this will ensure that the hardware will only need to
>| >fetch at most one more Z-block in the middle of the packet.  In fact it
>| >might be desirable for hardware to always try to maintain the next
>| >Z-block pre-fetched so that the fetch doesn't need to be done while the
>| >packet is arriving. >>
>| >
>| >Rergards,
>| >Sean Ganjooi
>| 
>| OpenHCI 0.91 section 8.1.2 places limits on the modifications that
>| software may make to AR descriptors that may have been prefetched,
>| but does not describe how much prefetch there can be.
>| 
>| 0.91 section 10.1 states that an IR DMA context program may not be
>| modified at all while it is running, except to rewrite the branch
>| address of the final descriptor.  This seems overly restrictive to
>| me, but it certainly makes most prefetching safe.
>| 
>| I can't find aynthing in 0.91 that gives rules for prefetch on
>| transmit contexts.
>| 
>| Although I had not expected any implementation to actually prefetch
>| any more than the current descriptor block (Z block), we should still
>| give clear guidelines in OpenHCI regarding how much prefetch software
>| must allow for.
>| 
>| --------------------------------------
>| Eric Anderson            ewa@apple.com
>| Apple Computer, Inc.     (408)974-8187
>| --------------------------------------
>| 
>| 
>| 
>| 
>




From:	DavidW@bangate.compaq.com
Sent:	Friday, February 07, 1997 9:29 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: RE: max_rec and OpenHCI

Just wanted to add a small amount to Eric's reply.  For asynch request receive 
using the single FIFO scheme, one will need to prefetch at least one Z block 
so that the link side of the FIFO will know that there is space available.

David

"Eric W. Anderson" <ewa@apple.com> Wrote:
| 
| 
| >Hi,
| >In general, is it safe to prefetch more than one Z block into
| >the HC ?
| >
| >In a message dated 97-02-01 22:06:51 EST, jfuller@MICROSOFT.com (John Nels
| >Fuller) writes:
| >
| ><< It was our intent that the only hardware restrictions on max_rec be
| >those defined by the maximum size asynchronous packet for the particular
| >speed of PHY that is used.  It should be possible, for example, to
| >receive a packet that is larger than the receive FIFO.  To accommodate
| >this we have specified the recovery mechanisms for FIFO overrun.  When
| >software sets max_rec it is contracting to provide buffer descriptors in
| >the AR request context that are at least large enough to receive the
| >max_rec packet, this will ensure that the hardware will only need to
| >fetch at most one more Z-block in the middle of the packet.  In fact it
| >might be desirable for hardware to always try to maintain the next
| >Z-block pre-fetched so that the fetch doesn't need to be done while the
| >packet is arriving. >>
| >
| >Rergards,
| >Sean Ganjooi
| 
| OpenHCI 0.91 section 8.1.2 places limits on the modifications that
| software may make to AR descriptors that may have been prefetched,
| but does not describe how much prefetch there can be.
| 
| 0.91 section 10.1 states that an IR DMA context program may not be
| modified at all while it is running, except to rewrite the branch
| address of the final descriptor.  This seems overly restrictive to
| me, but it certainly makes most prefetching safe.
| 
| I can't find aynthing in 0.91 that gives rules for prefetch on
| transmit contexts.
| 
| Although I had not expected any implementation to actually prefetch
| any more than the current descriptor block (Z block), we should still
| give clear guidelines in OpenHCI regarding how much prefetch software
| must allow for.
| 
| --------------------------------------
| Eric Anderson            ewa@apple.com
| Apple Computer, Inc.     (408)974-8187
| --------------------------------------
| 
| 
| 
| 
From:	schroed@us.ibm.com
Sent:	Friday, February 07, 1997 11:51 AM
To:	1394ohci-l@austin.ibm.com
Subject:	unsubcribe

Classification:
Prologue:
Epilogue: Regards,

Frank

Frank Schroeder (512) 838-9264
OS/2 Device Driver Development,
LAN: ausnotes(schroed),
VM:  bcrvm1(schroede),
Internet:  fschroeder@vnet.ibm.com

Please remove me from the 1394 Open HCI reflector.  Thanks.
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Friday, February 07, 1997 8:16 AM
To:	1394ohci-l
Subject:	Various Files on the FTP site

Hi,

   Please note that foils from the first and second 
conferences and the .91 OpenHCI specification are
 at:

ftp://www.austin.ibm.com/pub/chrptech/1394ohci

Please note that you must put "ftp://" (not "http://")
in front of the site if accessing it from your web 
browser.

  Best Regards, 
  Lee
From:	Yehuda Peled (972-4-8296149) [PELED@HAIFASC3.HAIFA.IBM.COM]
Sent:	Monday, February 10, 1997 6:22 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Some HCI 0.91 issues

- Section 1.3.5. Dual Phase retry.
Does the HC must support the Dual Phase retry protocol for received
packets ?
Please note that this is not a simple mechanism, and it is optional
by the 1394 spec.
Are there any devices that use the Dual Phase retry protocol ?

- Section 3.3. Asynchronous Receive response and request packets.
According to the HCI spec the HC can not discard incoming request
packets if there is no place in the DMA context. The solution is to use
a special FIFO for Async request packets or a special counters to insure
 that we accept requests only if there is place for them in the memory.
In the HCI workshop I understood that the main target of this mechanism
 is to protect the HC from hostel nodes that send long write requests,
 and will block the system memory.

I agree that there should be 2 DMA contexts, but the HC should be allowed
 to discard the request packets if there is no place in the DMA
 context. In this way we protect the system from the hostel nodes,
 without any complexity in the HC.
What do you think ?

- Section 9.1.4 Time stamp value.
What is the purpose of the time stamp value in the Isoc transmit
descriptor ?


Thanks
 Yehuda
From:	cylin@sis.com.tw
Sent:	Monday, February 10, 1997 6:47 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Changing multiChanMode bit and IRMultiChanMaskHi/Lo

DavidW@bangate.compaq.com Wrote:
>IRMultiCHanMaskHi and Lo can be changed at any time.  Certain fields of 
>ContextControl (bits 28-31) should not be changed unless _run_ is zero (I know 
>the spec says that active should be 0 but that's not always enough).
>
>The spec explains when run, active dead and wake bits can be changed.
>
>David
>
1) The spec. does not specify when multiChanMode bit can be changed.
Can someone clarify this?
2) If IRMultiCHanMaskHi and Lo can be changed at any time, then if,
for example, channel 4 packet is disabled at the middle of receiving it,
what does s/w exepect the contents of the the multiChanMode context? If,
at the same time, there is a single mode context for channel 4, then
what does s/w exepect?

>cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
>| 
>| Hi, all:
>| 
>| Sorry to bring this question up this late. I hope someone could 
>| raise it in the conference. Both OHCI0.9 and 0.91 does not
>| clearly specify when multiChanMode bit in IR contextControl register
>| and IRMultiChanMaskHi/Lo can be set/cleared. I suppose they can only 
>| be changed when contextControl.active is zero, correct?
>| 
>| Thanks for your time and answer,
>| 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	DavidW@bangate.compaq.com
Sent:	Monday, February 10, 1997 7:35 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Changing multiChanMode bit and IRMultiChanMaskHi/Lo

See below.

David

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| DavidW@bangate.compaq.com Wrote:
| >IRMultiCHanMaskHi and Lo can be changed at any time.  Certain fields of 
| >ContextControl (bits 28-31) should not be changed unless _run_ is zero (I 
know 
| >the spec says that active should be 0 but that's not always enough).
| >
| >The spec explains when run, active dead and wake bits can be changed.
| >
| >David
| >
| 1) The spec. does not specify when multiChanMode bit can be changed.
| Can someone clarify this?

OHCI does not need to prevent multiChanMode bit from being changed at any 
time.  SW would be ill addvised to change this bit while run is set in the 
context.

| 2) If IRMultiCHanMaskHi and Lo can be changed at any time, then if,
| for example, channel 4 packet is disabled at the middle of receiving it,
| what does s/w exepect the contents of the the multiChanMode context? If,
| at the same time, there is a single mode context for channel 4, then
| what does s/w exepect?

The expectation is that the HC would decide where to put the packet and then 
put it there.  It would not remember that it is receiving for channel 4 and 
then stop receiving that packet when the bit got turned off.

If there is a singe mode for the channel, then SW would expect that the data 
would stop going to the multi channel mode and start going to the single mode 
(or vice versa.)  There is no way for SW to synchronize the start and stop of 
a channel being handled by multi-channel mode.

| 
| >cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| >| 
| >| Hi, all:
| >| 
| >| Sorry to bring this question up this late. I hope someone could 
| >| raise it in the conference. Both OHCI0.9 and 0.91 does not
| >| clearly specify when multiChanMode bit in IR contextControl register
| >| and IRMultiChanMaskHi/Lo can be set/cleared. I suppose they can only 
| >| be changed when contextControl.active is zero, correct?
| >| 
| >| Thanks for your time and answer,
| >| 
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Monday, February 10, 1997 8:10 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Some HCI 0.91 issues

See bleow.

"Yehuda Peled (972-4-8296149)" <PELED@HAIFASC3.HAIFA.IBM.COM> Wrote:
| 
| - Section 1.3.5. Dual Phase retry.
| Does the HC must support the Dual Phase retry protocol for received
| packets ?

I think the spec specifically says that we only support single phase retry.

| Please note that this is not a simple mechanism, and it is optional
| by the 1394 spec.
| Are there any devices that use the Dual Phase retry protocol ?
| 
| - Section 3.3. Asynchronous Receive response and request packets.
| According to the HCI spec the HC can not discard incoming request
| packets if there is no place in the DMA context. The solution is to use
| a special FIFO for Async request packets or a special counters to insure
|  that we accept requests only if there is place for them in the memory.
| In the HCI workshop I understood that the main target of this mechanism
|  is to protect the HC from hostel nodes that send long write requests,
|  and will block the system memory.
| 
| I agree that there should be 2 DMA contexts, but the HC should be allowed
|  to discard the request packets if there is no place in the DMA
|  context. In this way we protect the system from the hostel nodes,
|  without any complexity in the HC.
| What do you think ?

Spec does _not_ disallow discarding of request packets.  However, we don't 
want to encourage implemenatations that simply discard requests when there's 
no room in the request context.

Protocols like SBP-2 suffer greatly when we discard write requests.  If a 
status write gets lost (it's a write to the portion of memory space to which 
HC always returns ack_complete) it's kind of hard for the SW to recover 
because the timing of commands is not deterministic.  I'm not sure how SW is 
going to recover if the HC starts droping the status write requests but I 
can't imagine that it is a pleasant thing to have to deal with.

| 
| - Section 9.1.4 Time stamp value.
| What is the purpose of the time stamp value in the Isoc transmit
| descriptor ?

Purpose is just like it says in the description of timeStamp in Table 9-3.  SW 
can use this value to determine if there has been any cycle slippage (happens 
when skip address points to the same Z-block.)


| 
| 
| Thanks
|  Yehuda
| 
From:	calvinn@lsi.sel.sony.com
Sent:	Monday, February 10, 1997 12:00 PM
To:	1394ohci-l@austin.ibm.com
Cc:	calvinn@lsi.sel.sony.com
Subject:	Little-Endian


	I don't really understand the purpose of using 2 flags
	HCControl.noByteSwapData and/or PCI_HCI_Control.PCI_Global_Swap 
	in Little-Endian systems. They seem redundant to me. Please
	explain. Thanks.

===================================================================
| Calvin Nguyen                 | Tel: (408) 955-5228             |
| Sony Research Labs            | Fax: (408) 955-5180             |
| LSI Systems Laboratory        | email: calvinn@lsi.sel.sony.com |
| 3300 Zanker Rd.   M/S SJ3D3   |                                 |
| San Jose, CA  95134-4591      |                                 |
===================================================================
From:	macomber@thoreau.nsc.com
Sent:	Monday, February 10, 1997 1:02 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Little-Endian

Hi,

> Calvin Nguyen writes:
> 
> 	I don't really understand the purpose of using 2 flags
> 	HCControl.noByteSwapData and/or PCI_HCI_Control.PCI_Global_Swap 
> 	in Little-Endian systems. They seem redundant to me. Please
> 	explain. Thanks.

The HCControl.noByteSwapData bit only affects the packet data, while
the PCI_HCI_Control.PCI_Global_Swap bit affects all transfers.  In
other words, if HCControl.noByteSwapData is CLEAR the control portions
of the descriptor accesses are not swapped, while all packet data
accesses are swapped.

As I understand it the Global Swap bit is intended for big endian
(PowerPC) systems that have a little-endian bus (PCI) and include
hardware that automatically swaps the bytes between PCI and host
memory.  This saves a software byte swap operation for 32-bit natural
words (ie, descriptors).  Without the Global Swap bit, the HC would
need to be configured for big endian data and software would have to
fiddle with the descriptor control info.

	- Robert

-- 
Robert L. Macomber MS 10-26   Phone: (207) 775-4677
National Semiconductor Corp.  Fax:   (207) 761-6108
333 Western Avenue            Email: macomber@thoreau.nsc.com
South Portland, Maine 04106   Advanced Development Center
From:	calvinn@lsi.sel.sony.com
Sent:	Tuesday, February 11, 1997 12:10 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Little Endian


Thanks for your reply, Robert.

I have a few more questions about Little Endian:

1. Little Endian & Data MisAlignment.
   I wonder how the data will be stored in memory in Little Endian mode if
   the Memory Address is not a multiple of 4 ?
   For example, if I have 6 bytes of data send from 1394 bus to HC, and the
   Memory Destination Address is 201. Assuming the data is arranged in the 
   FIFO as shown below:

	bits    31   24 23   16 15    8 7	0 
               +---------------------------------+
	       |   01  |  02   |   03  |   04    |
               +---------------------------------+
	       |   05  |  06   |       |	 |	
               +---------------------------------+

   Should the data be stored in the memo as shown below:

   a)						   Memory 
	bits    31   24 23   16 15    8 7	0  Address
               +---------------------------------+
	       |   02  |  03   |   04  |         |  200
               +---------------------------------+
	       |   06  |       |       |   01    |  204
               +---------------------------------+
	       |       |       |       |   05    |  208
               +---------------------------------+

   or

   b)						   Memory 
	bits    31   24 23   16 15    8 7	0  Address
               +---------------------------------+
	       |       |       |       |   01    |  196
               +---------------------------------+
	       |   02  |  03   |   04  |   05    |  200
               +---------------------------------+
	       |   06  |       |       |         |  204
               +---------------------------------+

   I think case b) makes more sense. 



2. Little Endian & Buffer-Fill mode
   Assuming 2 packets of data are sent from 1394 bus to HC. the first packet
   has 6 bytes of data as shown in the previous example; the second packet 
   has 5 bytes of data & arranged in the FIFO as shown:

	bits    31   24 23   16 15    8 7	0 
               +---------------------------------+
	       |   11  |  12   |   13  |   14    |
               +---------------------------------+
	       |   15  |       |       |	 |	
               +---------------------------------+

   Assume the Destination Address is also 201, how should data is arranged
   in memory ?

   a)						   Memory 
	bits    31   24 23   16 15    8 7	0  Address
               +---------------------------------+
	       |   02  |  03   |   04  |         |  200
               +---------------------------------+
	       |   14  |  05   |   06  |   01    |  204
               +---------------------------------+
	       |   15  |  11   |   12  |   13    |  208
               +---------------------------------+
   
   or

   b)						   Memory 
	bits    31   24 23   16 15    8 7	0  Address
               +---------------------------------+
	       |       |       |       |   01    |  196
               +---------------------------------+
	       |   02  |  03   |   04  |   05    |  200
               +---------------------------------+
	       |   06  |  11   |   12  |   13    |  204
               +---------------------------------+
	       |   14  |  15   |       |         |  208
               +---------------------------------+


===================================================================
| Calvin Nguyen                 | Tel: (408) 955-5228             |
| Sony Research Labs            | Fax: (408) 955-5180             |
| LSI Systems Laboratory        | email: calvinn@lsi.sel.sony.com |
| 3300 Zanker Rd.   M/S SJ3D3   |                                 |
| San Jose, CA  95134-4591      |                                 |
===================================================================

From:	macomber@thoreau.nsc.com
Sent:	Tuesday, February 11, 1997 7:28 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Little Endian

Hi Calvin,

Response embedded below...

> Thanks for your reply, Robert.
> 
> I have a few more questions about Little Endian:
> 
> 1. Little Endian & Data MisAlignment.
>    I wonder how the data will be stored in memory in Little Endian mode if
>    the Memory Address is not a multiple of 4 ?
>    For example, if I have 6 bytes of data send from 1394 bus to HC, and the
>    Memory Destination Address is 201. Assuming the data is arranged in the 
>    FIFO as shown below:
> 
> 	bits     31    24 23   16 15    8 7       0 
>                +---------------------------------+
>                |   01  |  02   |   03  |   04    |
>                +---------------------------------+
>                |   05  |  06   |       |	   |	
>                +---------------------------------+
> 
>    Should the data be stored in the memo as shown below:
> 
>    a)						   Memory 
> 	bits     31    24 23   16 15    8 7	0  Address
>                +---------------------------------+
>                |   02  |  03   |   04  |         |  200
>                +---------------------------------+
>                |   06  |       |       |   01    |  204
>                +---------------------------------+
>                |       |       |       |   05    |  208
>                +---------------------------------+
> 
>    or
> 
>    b)						   Memory 
> 	bits     31    24 23   16 15    8 7  	0  Address
>                +---------------------------------+
>                |       |       |       |   01    |  196
>                +---------------------------------+
>                |   02  |  03   |   04  |   05    |  200
>                +---------------------------------+
>                |   06  |       |       |         |  204
>                +---------------------------------+
> 
>    I think case b) makes more sense. 

Neither.  It would be stored like this:
                                        
 bytes     3        2       1       0
  bits  31    24 23   16 15    8 7     0 
        +-------------------------------+
        |       |       |       |       |  196
        +-------------------------------+
        |   03  |  02   |   01  |       |  200
        +-------------------------------+
        |       |  06   |   05  |  04   |  204
        +-------------------------------+

such that the ascending memory bytes have ascending packet bytes...

   address   data
    201    :  01
    202    :  02
    203    :  03
    204    :  04
    205    :  05
    206    :  06

While in a natively wired big endian system (with the OpenHCI data
swapping turned off) it would be stored like this:

 bytes     0        1       2       3
  bits  31    24 23   16 15    8 7     0 
        +-------------------------------+
        |       |       |       |       |  196
        +-------------------------------+
        |       |  01   |   02  |  03   |  200
        +-------------------------------+
        |  04   |  05   |   06  |       |  204
        +-------------------------------+

again with the ascending memory bytes having ascending packet bytes...

   address   data
    201    :  01
    202    :  02
    203    :  03
    204    :  04
    205    :  05
    206    :  06

> 
> 
> 2. Little Endian & Buffer-Fill mode
>    Assuming 2 packets of data are sent from 1394 bus to HC. the first packet
>    has 6 bytes of data as shown in the previous example; the second packet 
>    has 5 bytes of data & arranged in the FIFO as shown:
> 
> 	bits     31    24 23   16 15    8 7       0 
>                +---------------------------------+
>                |   11  |  12   |   13  |   14    |
>                +---------------------------------+
>                |   15  |       |       |         |	
>                +---------------------------------+
> 
>    Assume the Destination Address is also 201, how should data is arranged
>    in memory ?
> 
>    a)						   Memory 
> 	bits     31    24 23   16 15    8 7	0  Address
>                +---------------------------------+
>                |   02  |  03   |   04  |         |  200
>                +---------------------------------+
>                |   14  |  05   |   06  |   01    |  204
>                +---------------------------------+
>                |   15  |  11   |   12  |   13    |  208
>                +---------------------------------+
>    
>    or
> 
>    b)						   Memory 
> 	bits     31    24 23   16 15    8 7	0  Address
>                +---------------------------------+
>                |       |       |       |   01    |  196
>                +---------------------------------+
>                |   02  |  03   |   04  |   05    |  200
>                +---------------------------------+
>                |   06  |  11   |   12  |   13    |  204
>                +---------------------------------+
> 	         |   14  |  15   |       |         |  208
>                +---------------------------------+

Assuming that you're talking about buffer-fill mode for an Isochronous
receive context without header/trailers and are imagining packets that
are not sized as multiple quadlets...the packet data would get packed
contiguously in the buffer like this:

 bytes     3        2       1       0
  bits  31    24 23   16 15    8 7     0 
        +-------------------------------+
        |       |       |       |       |  196
        +-------------------------------+
        |   03  |  02   |   01  |       |  200
        +-------------------------------+
        |   11  |  06   |   05  |  04   |  204
        +-------------------------------+
        |   15  |  14   |   13  |  12   |  208
        +-------------------------------+

For a good tutorial on OpenHCI byte swapping issues you should look at
David Wooten's presentation slides.  These can be found at...

    ftp://www.austin.ibm.com/pub/chrptech/1394ohci/bswap2.pdf

	- Robert

-- 
Robert L. Macomber MS 10-26   Phone: (207) 775-4677
National Semiconductor Corp.  Fax:   (207) 761-6108
333 Western Avenue            Email: macomber@thoreau.nsc.com
South Portland, Maine 04106   Advanced Development Center
From:	daisy@sis.com.tw
Sent:	Wednesday, February 12, 1997 12:14 AM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Cc:	daisy@sis.com.tw
Subject:	quadlet-aligned address for IR

Hi,

I have a question about the description of quadlet-aligned address for IR, 
in OHCI v0.91 page98, Table 10-1,

It says, if in packet-per-buffer mode and receiving headers, dataAddress
should be quadlet aligned.

Is it describing Figure 10-11(packet-per-buffer mode with header/trailer)
only, or also describing Figure 10-9(buffer fill mode with header/trailer)?

I think the address should be quadlet-aligned when buffer fill mode with
header/trailer, am I right ?

Also, since OHCI doesn't restrict the address should be quadlet-aligned
for packet-per-buffer mode without header/trailer, I think Figure 10-12
will be better if the starting address of the buffer is not quadlet-aligned.

Thanks for your time and answer,

Y.J. Chao 
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	klashman@meow.East.Sun.COM
Sent:	Thursday, February 13, 1997 11:02 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: quadlet-aligned address for IR

Comments below.

>From: daisy@sis.com.tw (Yen-Jiuan Chao)
>Subject: quadlet-aligned address for IR
>
>Hi,
>
>I have a question about the description of quadlet-aligned address for IR, 
>in OHCI v0.91 page98, Table 10-1,
>
>It says, if in packet-per-buffer mode and receiving headers, dataAddress
>should be quadlet aligned.
>
>Is it describing Figure 10-11(packet-per-buffer mode with header/trailer)
>only, or also describing Figure 10-9(buffer fill mode with header/trailer)?
>
>I think the address should be quadlet-aligned when buffer fill mode with
>header/trailer, am I right ?
>
>Also, since OHCI doesn't restrict the address should be quadlet-aligned
>for packet-per-buffer mode without header/trailer, I think Figure 10-12
>will be better if the starting address of the buffer is not quadlet-aligned.

Yes, all buffers that will contain headers must be quadlet aligned.
Buffers containing data _only_ do not have to be quadlet aligned.

This actually makes Figure 10-11 difficult to draw because if you
are doing packet-per-buffer and lumping headers & data together into
the same buffer then it's quadlet aligned.  But if you are doing
packet-per-buffer and have a separate descriptor (buffer) to fit just the
header and then a separate one for the data, the data does not
have to be quadlet aligned, but the header still does.

I'll attempt to clear this all up for .92.

>
>Thanks for your time and answer,
>
>Y.J. Chao 
>====================================
>Yen-Jiuan Chao (Daisy)
>Design Engineer
>Basic Technology Group
>Silicon Integrated Systems Corp.(SiS)
>Phone  : 886-3-5774922 ext. 4315
>Fax    : 886-3-5790651
>E-mail : daisy@sis.com.tw
>=====================================
>
>

Diana


From:	mis@aluxs.micro.lucent.com
Sent:	Friday, February 14, 1997 1:20 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Multiple AT pkts per fairness interval

Hi all,

Questions about AT responses (and Physical Responses): 
Is there a requirement that responses that SW queues into a chain of descriptor blocks go out in the same order as queued? 
Is it "desirable" to fill AT FIFO with multiple packets from the SAME context before getting an Ack_status from Link?  
May Physical Responses and AT Responses block each other due to busies? 

The basis for the questions is in 1394A and retries.
 
During last workshop there was a mention of 1394A allowing multiple AT response packets to be sent during one fairness interval. To support multiple resp pkts per fairness interval AT DMA may stuff AT FIFO full of responses. When link goes to transmit these, some may encounter busy acks. If link is built to discard an AT pkt whether sucessfull or not and notify system side of Ack_status on a per packet basis, then the ordering of responses will not be the same as ordering intended by SW.

Thank you for your time.
Mike.
From:	DavidW@bangate.compaq.com
Sent:	Friday, February 14, 1997 3:55 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Multiple AT pkts per fairness interval

Mike,

Even though there is no general rule on 1394 that responses be delivered in 
order, in order responses is not precluded by OpenHCI.  SW would have to queue 
then one at a time in order to guarantee that they completed in order.  
Alternative is for the device that wants in order responses not to return busy 
when the responses show up.

There is also no guarantee that physical responses are going to be returned in 
order if the device returns busy.  If a device issues multiple physical read 
requests, the host controller may be able to queue more than one of them.  It 
will probably try to return them in order (but it is not guaranteed -- yet) 
and if the requesting device returns busy on an earlier response (up to the SW 
setable limit) the first response will get dropped (which leads to a timeout) 
and the HC will go on to a next request.  This will cause out of order 
completions.

Also, there is no such thing as a 'context' on 1394.  In particular, a node 
can have multiple contexts (like the OHCI controller).  There is no way to 
support all the possible groupings of node ID's, offsets, and tags that one 
might conceivably define as a context.

David


mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| Hi all,
| 
| Questions about AT responses (and Physical Responses): 
| Is there a requirement that responses that SW queues into a chain of 
descriptor 
| blocks go out in the same order as queued? 
| Is it "desirable" to fill AT FIFO with multiple packets from the SAME 
context 
| before getting an Ack_status from Link?  
| May Physical Responses and AT Responses block each other due to busies? 
| 
| The basis for the questions is in 1394A and retries.
|  
| During last workshop there was a mention of 1394A allowing multiple AT 
response 
| packets to be sent during one fairness interval. To support multiple resp 
pkts 
| per fairness interval AT DMA may stuff AT FIFO full of responses. When link 
goes 
| to transmit these, some may encounter busy acks. If link is built to discard 
an 
| AT pkt whether sucessfull or not and notify system side of Ack_status on a 
per 
| packet basis, then the ordering of responses will not be the same as 
ordering 
| intended by SW.
| 
| Thank you for your time.
| Mike.
| 
From:	daisy@sis.com.tw
Sent:	Friday, February 14, 1997 8:40 PM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Cc:	daisy@sis.com.tw
Subject:	packet format of bus_reset packet

Hi, all,

I have a question about the packet format of bus reset packet,
in OHCI v0.91, page 74, Figure 8-6, 

the trailer format is defined as the most significant byte reserved, 
different from other Asyn. request packet.

My question is, should hardware fill the reserved field as zero ? 
If yes, will it be better that OHCI define the reserved filed in trailer 
quadlet as other Asyn request packet, ie. the higher byte of xferStatus ? 
Then the hardware can just treat the bus_reset packet as the normal
Asyn. request packet with error code = 5'h19 and speed = 3'h0.

Thanks for your time and answer,

Y.J. Chao  
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================

From:	PJohansson@aol.com
Sent:	Sunday, February 16, 1997 5:38 PM
To:	1394ohci-l@austin.ibm.com
Subject:	max_rec and OpenHCI

This is another topic on which there has been discussion, but I'm not sure
closure has been achieved.

At one point David Wooten suggested that max_rec in the Bus Options register
be initialized to a maximum value by the OpenHCI implementation----perhaps at
power reset or chip reset time.

I agree that this would be workable but would still recommend creating a
separate, read-only max_rec field in some other register. Perhaps bits 12-15
of the Version register...

Could one of the following decisions be taken for OpenHCI and documented:

 a) All OpenHCI hardware implementations shall support the largest max_rec
value for the speed of the PHY to which they are connected or with which they
are integrated;

 b) All OpenHCI hardware shall initialize the max_rec field of the Bus
Options register to the maximum value supported by the implementation. This
field shall be initialized upon either a power reset or chip reset; or

 c) All OpenHCI hardware shall implement a max_rec field in the Version
register. This read-only field shall report the maximum value of max_rec that
the implementation supports in the Bus Options register.

As I've indicated in this and previous messages, I favor choice c). I think
choice a) is the least favorable----because I am aware of at least one
implementation in progress where there is a desire to support a max_rec value
smaller than what the maximum PHY speed would permit.

At any rate, some choice needs to be made and documented in the next draft of
OpenHCI.

Regards,

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com

From:	PJohansson@aol.com
Sent:	Sunday, February 16, 1997 5:44 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Posted Writes and SBP-2

Hello, all!

I'd like to revive this discussion because I'm not sure that consensus has
been reached. At any rate, I am unclear on what changes are expected in the
next draft of OpenHCI to address posted writes.

A quick recap: The problem of ordering posted writes arises with respect to
SBP-2 because there are likely to be two DMA contexts, independent of each
other, that handle key components of an SBP-2 command like a disk READ. The
physical write unit likely takes care of the many data transfer packets the
disk utilizes to store the READ data in host memory. The general receive
queue is the likely destination of the status packet that signals to the host
that the command has finished.

Upon receipt of the status packet, the host needs to rely on the fact that
all the preceding data writes (potentially posted) have completed. Hence the
coordination problem between the physical write DMA context and the general
receive DMA context.

I agree with Jerry Hauck's assertion that the following rules need to become
part of OpenHCI:

  1) Posted writes MAY pass any other request in ANY inbound FIFO or DMA
context
  2) Requests in ANY inbound FIFO or DMA context SHALL NOT pass any posted
write.

Implementation choices for the physical write unit and the general
(asynchronous) receive DMA context may require some ingenuity but I believe
that these constraints are essential.

Although the facility to support posted writes is not a requirement of
OpenHCI, this is an excellent time to plead that posted writes be STRONGLY
RECOMMENDED for OpenHCI. An OpenHCI without such support will perform poorly
when it comes time to support an SBP-2 device like a disk. I have some
calculations (available in a set of slides) that demonstrate a significant
loss of throughput for disk READs if unified Serial Bus write transactions
are not available. Without posted writes, the block write transactions
associated with a disk READ revert to split transactions with an estimated
throughput loss between 5% and 10% (as compared to unified transactions).

Sincerely,

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com


From:	mjlu@sis.com.tw
Sent:	Sunday, February 16, 1997 6:53 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Questions about Isochronous Transmit DMA

Hi,all:

I have some questions about Isochronous Transmit DMA:
1.In OHCI v0.91,page 92, the first sentence in the last paragraph: it 
describes that "for each cycle, the IT DMA controller will complete one 
descriptor block for each active IT DMA context". Does this restrict IT DMA 
controller should not do more than one descriptor block for each active IT 
DMA context in each cycle? And why set this restriction ?

2.Assume there are 4 IT contexts, should IT DMA controller keep the transmit 
data the same order in every cycle ? For example: A,B,C,D are the 4 
contexts, in cycle 2000, data order in DATA FIFO is A->B->C->D, so the iso 
packet in 1394 bus will be A->B->C->D, should HC maintain the same order in 
next cycle? 
        cycle                   2000                             2001        
                   
        data order            A->B->C->D                A->B->C->D(???)
2.1 If it is required for IT DMA controller to maintain the data order, in 
the following example, which one is correct. in cycle 2000,only context 
A,B,D are enabled, in cycle 2001,context A,B,C,D are enabled.
case1
          cycle           2000                  2001
2002         
        data order    A->B->D       A->B->C->D       A->B->C->D
case2
         cycle            2000                   2001                   2002

        data order    A->B->D       C->A->B->D        C-> A->B->D
case3 
        cycle             2000                   2001                   2002

        data order    A->B->D        A->B->D->C        A->B->D->C

Which case will be correct?

Thanks for your time and answer.
From:	DavidW@bangate.compaq.com
Sent:	Monday, February 17, 1997 12:04 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Questions about Isochronous Transmit DMA

Responses below.

David

mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
| 
| Hi,all:
| 
| I have some questions about Isochronous Transmit DMA:
| 1.In OHCI v0.91,page 92, the first sentence in the last paragraph: it 
| describes that "for each cycle, the IT DMA controller will complete one 
| descriptor block for each active IT DMA context". Does this restrict IT DMA 
| controller should not do more than one descriptor block for each active IT 
| DMA context in each cycle? And why set this restriction ?

The restriction is that there is only one descriptor block processed for each 
cycle's worth of data.  That does not mean that only one descriptor blocks may 
be processed during any particular bus cycle.  In fact there is no direct 
synchronization between the time the data is put into the FIFO and the time 
that it is removed.  Please note that when I say that the descriptor block is 
processed, I mean that the data associated with a descriptor block is placed 
in the isochronous output FIFO or that the skip address of a descriptor is 
taken.

| 
| 2.Assume there are 4 IT contexts, should IT DMA controller keep the transmit 

| data the same order in every cycle ? For example: A,B,C,D are the 4 
| contexts, in cycle 2000, data order in DATA FIFO is A->B->C->D, so the iso 
| packet in 1394 bus will be A->B->C->D, should HC maintain the same order in 
| next cycle? 
|         cycle                   2000                             2001        

|                    
|         data order            A->B->C->D                A->B->C->D(???)

I don't think that we require that the contexts be processed in the same 
order.


| 2.1 If it is required for IT DMA controller to maintain the data order, in 
| the following example, which one is correct. in cycle 2000,only context 
| A,B,D are enabled, in cycle 2001,context A,B,C,D are enabled.
| case1
|           cycle           2000                  2001
| 2002         
|         data order    A->B->D       A->B->C->D       A->B->C->D
| case2
|          cycle            2000                   2001                   2002
| 
|         data order    A->B->D       C->A->B->D        C-> A->B->D
| case3 
|         cycle             2000                   2001                   2002
| 
|         data order    A->B->D        A->B->D->C        A->B->D->C
| 
| Which case will be correct?

Ordering not important.

| 
| Thanks for your time and answer.
| 
| 
From:	John Nels Fuller
Sent:	Monday, February 17, 1997 2:07 PM
To:	'PJohansson@aol.com'; '1394ohci-l@austin.ibm.com'
Subject:	RE: Posted Writes and SBP-2

I would suggest that posted writes may not pass another posted write.
Otherwise, I think that these rules are fine.

>-----Original Message-----
>From:	PJohansson@aol.com [SMTP:PJohansson@aol.com]
>Sent:	Sunday, February 16, 1997 5:44 PM
>To:	1394ohci-l@austin.ibm.com
>Subject:	Posted Writes and SBP-2
>
>Hello, all!
>
>I'd like to revive this discussion because I'm not sure that consensus has
>been reached. At any rate, I am unclear on what changes are expected in the
>next draft of OpenHCI to address posted writes.
>
>A quick recap: The problem of ordering posted writes arises with respect to
>SBP-2 because there are likely to be two DMA contexts, independent of each
>other, that handle key components of an SBP-2 command like a disk READ. The
>physical write unit likely takes care of the many data transfer packets the
>disk utilizes to store the READ data in host memory. The general receive
>queue is the likely destination of the status packet that signals to the host
>that the command has finished.
>
>Upon receipt of the status packet, the host needs to rely on the fact that
>all the preceding data writes (potentially posted) have completed. Hence the
>coordination problem between the physical write DMA context and the general
>receive DMA context.
>
>I agree with Jerry Hauck's assertion that the following rules need to become
>part of OpenHCI:
>
>  1) Posted writes MAY pass any other request in ANY inbound FIFO or DMA
>context
>  2) Requests in ANY inbound FIFO or DMA context SHALL NOT pass any posted
>write.
>
>Implementation choices for the physical write unit and the general
>(asynchronous) receive DMA context may require some ingenuity but I believe
>that these constraints are essential.
>
>Although the facility to support posted writes is not a requirement of
>OpenHCI, this is an excellent time to plead that posted writes be STRONGLY
>RECOMMENDED for OpenHCI. An OpenHCI without such support will perform poorly
>when it comes time to support an SBP-2 device like a disk. I have some
>calculations (available in a set of slides) that demonstrate a significant
>loss of throughput for disk READs if unified Serial Bus write transactions
>are not available. Without posted writes, the block write transactions
>associated with a disk READ revert to split transactions with an estimated
>throughput loss between 5% and 10% (as compared to unified transactions).
>
>Sincerely,
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>
>
From:	DavidW@bangate.compaq.com
Sent:	Monday, February 17, 1997 1:10 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Posted Writes and SBP-2

Peter,

Comments embedded below but...

I'd like you to answer an SBP-2 question for me.  How does SBP-2  recover from 
a lost status packet (assume o-o-o completion.)  Can happen if status 'queue' 
in mid-memory (above physical, below CSR) where all  writes are 'posted'.  We 
can lose packets to this space without having any SW notification that 
something has gone wrong.

David

PJohansson@aol.com Wrote:
| 
| Hello, all!
| 
| I'd like to revive this discussion because I'm not sure that consensus has
| been reached. At any rate, I am unclear on what changes are expected in the
| next draft of OpenHCI to address posted writes.
| 
| A quick recap: The problem of ordering posted writes arises with respect to
| SBP-2 because there are likely to be two DMA contexts, independent of each
| other, that handle key components of an SBP-2 command like a disk READ. The
| physical write unit likely takes care of the many data transfer packets the
| disk utilizes to store the READ data in host memory. The general receive
| queue is the likely destination of the status packet that signals to the 
host
| that the command has finished.
| 
| Upon receipt of the status packet, the host needs to rely on the fact that
| all the preceding data writes (potentially posted) have completed. Hence the
| coordination problem between the physical write DMA context and the general
| receive DMA context.
| 
| I agree with Jerry Hauck's assertion that the following rules need to become
| part of OpenHCI:
| 
|   1) Posted writes MAY pass any other request in ANY inbound FIFO or DMA
| context

Can they pass requests?  What about non-posted writes?

|   2) Requests in ANY inbound FIFO or DMA context SHALL NOT pass any posted
| write.

Asynch maybe. I reserve the right to push iso ahead of any asynch because we 
ain't got no flow control on iso.

A request received in the same fairness interval as a posted write can pass a 
posted write (since a device can only issue one request per fairness interval, 
we are guaranteed that requests received within a fairness interval are 
mutually exclusive.)

| 
| Implementation choices for the physical write unit and the general
| (asynchronous) receive DMA context may require some ingenuity but I believe
| that these constraints are essential.
| 
| Although the facility to support posted writes is not a requirement of
| OpenHCI, this is an excellent time to plead that posted writes be STRONGLY
| RECOMMENDED for OpenHCI. An OpenHCI without such support will perform poorly
| when it comes time to support an SBP-2 device like a disk. I have some
| calculations (available in a set of slides) that demonstrate a significant
| loss of throughput for disk READs if unified Serial Bus write transactions
| are not available. Without posted writes, the block write transactions
| associated with a disk READ revert to split transactions with an estimated
| throughput loss between 5% and 10% (as compared to unified transactions).


I share your desire to have posted writes, however...

Seems to me that the worst case is that write to host through put becomse the 
same a read from host throughput if we don't have posted writes.

The detrimental effect of non-posted writes is somewhat mitigated by the 
arbitration tricks that are available in 1394a.  Giving the host the ability 
to slap a response packet on damn near anything that comes its way should 
cause eliminate a portion of the overhead of a split response.  Even so, I 
still think that the posted write capability is of significant value.

| Sincerely,
| 
| Peter Johansson
| 
| Congruent Software, Inc.
| 3998 Whittle Avenue
| Oakland, CA  94602
| 
| (510) 531-5472
| (510) 531-2942 FAX
| 
| pjohansson@aol.com
| 
| 
| 
From:	John Nels Fuller
Sent:	Monday, February 17, 1997 3:12 PM
To:	'daisy@sis.com.tw'; '1394ohci-l@austin.ibm.com'
Subject:	RE: packet format of bus_reset packet

We should definitely allow the h/w to work in the way you describe.
We'll try to be clearer in the next rev of the document.

>-----Original Message-----
>From:	daisy@sis.com.tw [SMTP:daisy@sis.com.tw]
>Sent:	Friday, February 14, 1997 8:40 PM
>To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
>Cc:	daisy@sis.com.tw
>Subject:	packet format of bus_reset packet
>
>Hi, all,
>
>I have a question about the packet format of bus reset packet,
>in OHCI v0.91, page 74, Figure 8-6, 
>
>the trailer format is defined as the most significant byte reserved, 
>different from other Asyn. request packet.
>
>My question is, should hardware fill the reserved field as zero ? 
>If yes, will it be better that OHCI define the reserved filed in trailer 
>quadlet as other Asyn request packet, ie. the higher byte of xferStatus ? 
>Then the hardware can just treat the bus_reset packet as the normal
>Asyn. request packet with error code = 5'h19 and speed = 3'h0.
>
>Thanks for your time and answer,
>
>Y.J. Chao  
>====================================
>Yen-Jiuan Chao (Daisy)
>Design Engineer
>Basic Technology Group
>Silicon Integrated Systems Corp.(SiS)
>Phone  : 886-3-5774922 ext. 4315
>Fax    : 886-3-5790651
>E-mail : daisy@sis.com.tw
>=====================================
>
From:	John Nels Fuller
Sent:	Monday, February 17, 1997 4:36 PM
To:	'1394ohci-l@austin.ibm.com'
Subject:	RE: max_rec and OpenHCI

If this is a vote then I vote for option a).

>-----Original Message-----
>From:	PJohansson@aol.com [SMTP:PJohansson@aol.com]
>Sent:	Sunday, February 16, 1997 5:38 PM
>To:	1394ohci-l@austin.ibm.com
>Subject:	max_rec and OpenHCI
>
>This is another topic on which there has been discussion, but I'm not sure
>closure has been achieved.
>
>At one point David Wooten suggested that max_rec in the Bus Options register
>be initialized to a maximum value by the OpenHCI implementation----perhaps at
>power reset or chip reset time.
>
>I agree that this would be workable but would still recommend creating a
>separate, read-only max_rec field in some other register. Perhaps bits 12-15
>of the Version register...
>
>Could one of the following decisions be taken for OpenHCI and documented:
>
> a) All OpenHCI hardware implementations shall support the largest max_rec
>value for the speed of the PHY to which they are connected or with which they
>are integrated;
>
> b) All OpenHCI hardware shall initialize the max_rec field of the Bus
>Options register to the maximum value supported by the implementation. This
>field shall be initialized upon either a power reset or chip reset; or
>
> c) All OpenHCI hardware shall implement a max_rec field in the Version
>register. This read-only field shall report the maximum value of max_rec that
>the implementation supports in the Bus Options register.
>
>As I've indicated in this and previous messages, I favor choice c). I think
>choice a) is the least favorable----because I am aware of at least one
>implementation in progress where there is a desire to support a max_rec value
>smaller than what the maximum PHY speed would permit.
>
>At any rate, some choice needs to be made and documented in the next draft of
>OpenHCI.
>
>Regards,
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA  94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>
From:	DavidW@bangate.compaq.com
Sent:	Monday, February 17, 1997 1:48 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Wait control for bufferFill IR

Can be used to filter packets that don't have the correct tag or to provide 
some initial synchronization.

David

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, all:
| 
| Will wait control be used for IR in bufferFill mode? If so, where
| can it be used?
| 
| Thanks for your time and answer,
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	John Nels Fuller
Sent:	Monday, February 17, 1997 5:24 PM
To:	'1394ohci-l@austin.ibm.com'
Subject:	RE: Wait control for bufferFill IR

The primary use in buffer-fill mode is to wait for a particular sync
value before starting the buffer.  For example, start receiving on a
start of frame sync.

>-----Original Message-----
>From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
>Sent:	Monday, February 17, 1997 1:48 PM
>To:	1394ohci-l@austin.ibm.com
>Subject:	re: Wait control for bufferFill IR
>
>Can be used to filter packets that don't have the correct tag or to provide 
>some initial synchronization.
>
>David
>
>cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
>| 
>| Hi, all:
>| 
>| Will wait control be used for IR in bufferFill mode? If so, where
>| can it be used?
>| 
>| Thanks for your time and answer,
>| 
>| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>| Chien-Yuh Lin
>| Design Engineer
>| Basic Technology Group
>| Silicon Intergrated Systems Corp.
>| Tel: 886-3-5774922 x 4326
>| Fax: 886-3-5778774
>| Email: cylin@sis.com.tw
>| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>| 
>| 
From:	PJohansson@aol.com
Sent:	Monday, February 17, 1997 7:57 PM
To:	DavidW@bangate.compaq.com; 1394ohci-l@austin.ibm.com
Subject:	Re: Posted Writes and SBP-2

Slightly revised rules:

 1) There are no ordering relationships between asynchronous and isochronous
packets.

 2) Posted asynchronous write requests MAY pass any other asynchronous
request in ANY inbound FIFO or DMA context.

 3) Asynchronous requests in ANY inbound FIFO or DMA context SHALL NOT pass
any posted asynchronous write request.

In a message dated 97-02-17 18:08:08 EST, DavidW@bangate.compaq.com writes:

<<Can they pass requests?  What about non-posted writes?>>

I may be being muddle-headed about this, but I don't see a problem with a
posted write request passing ANY other request that has reeived an
ack_pending. What ordering requirement of 1394 is violated here? An ordering
requirement that bridges would not be able to enforce anyway?
 
<<A request received in the same fairness interval as a posted write can pass
a 
 posted write (since a device can only issue one request per fairness
interval, 
 we are guaranteed that requests received within a fairness interval are 
 mutually exclusive.)>>

I agree with your assertion, but are fairness interval tokens going to be
passed in the incoming receive FIFO so that the DMA contexts know to which
fairness interval a particular group of requests belong? I can see how it
could be done but had never imagined that an OpenHCI implementation would be
that subtle. Is it worth it? I really don't have a clue...

<<Seems to me that the worst case is that write to host throughput becomes
the 
same a read from host throughput if we don't have posted writes.>>

Yes, this is so----but because I estimate that disk READ transactions (writes
to host memory) VASTLY outnumber disk WRITE transactions (reads from host
memory) I've always thought that the consequences of having disk READs
reduced to the same lesser level or performance as disk WRITEs was a matter
of concern.

Regards,

Peter


From:	PJohansson@aol.com
Sent:	Monday, February 17, 1997 7:56 PM
To:	DavidW@bangate.compaq.com; 1394ohci-l@austin.ibm.com
Subject:	Lost SBP-2 Status

In a message dated 97-02-17 18:08:08 EST, DavidW@bangate.compaq.com writes:

<< I'd like you to answer an SBP-2 question for me.  How does SBP-2  recover
from 
 a lost status packet (assume o-o-o completion.)  Can happen if status
'queue' 
 in mid-memory (above physical, below CSR) where all  writes are 'posted'.
 We 
 can lose packets to this space without having any SW notification that 
 something has gone wrong.
  >>

The initiator error recovery might depend upon the ordered vs. nonordered
behavior of the target.

If the target executes commands and reports completion status in order, it
might happen that a "downstream" ORB reports successful completion status
before a large time-out value at the initiator detected the missing status of
an earlier, "upstream" ORB. This is an example where later status would heal
the earlier lack of status. Not very likely, perhaps, but something that
might happen.

The more likely case is when command execution is unordered or there is no
providentially located "downstream" ORB whose status heals the omission:
ABORT TASK SET. The target's task set may well be reduced to the isolated
task that timed out by the time this is discovered, but even if not it's
really the only option.

Your question assumes a host bus error, since OpenHCI guarantees that there
was enough buffer space to receive the whole packet when the ack_complete was
posted back to the target. When there is a host bus error, the chances are
excellent (as John noted) that there's deep trouble in River City and a lost
status packet may be the most inconsequential of problems next to the likely
system crash.

Regards,

Peter


From:	Yehuda Peled [PELED@HAIFASC3.HAIFA.IBM.COM]
Sent:	Tuesday, February 18, 1997 2:01 AM
To:	1394OHCI-L@austin.ibm.com
Cc:	YENGEL@HAIFASC3.HAIFA.IBM.COM
Subject:	Re: Posted Writes and SBP-2

Comments embedded below.

>>Slightly revised rules:
>>
>> 1) There are no ordering relationships between asynchronous and isochronous
>>packets.
>>
>> 2) Posted asynchronous write requests MAY pass any other asynchronous
>>request in ANY inbound FIFO or DMA context.
>>
>> 3) Asynchronous requests in ANY inbound FIFO or DMA context SHALL NOT pass
>>any posted asynchronous write request.

What about posted writes that are forwarded to the DMA context (not
a Physical DMA). How can we insure that a physical read request will
not pass those posted writes ?
The problem is that there is no way to know when the device driver will
process those posted write.

>>
>>
>>Regards,
>>
>>Peter
>>
>>

Regards,
 Yehuda
From:	Yehuda Peled (972-4-8296149) [PELED@HAIFASC3.HAIFA.IBM.COM]
Sent:	Tuesday, February 18, 1997 2:10 AM
To:	1394ohci-l@austin.ibm.com

Please add Yehiel Engel (yengel@vnet.ibm.com) to the reflector.

Thanks
 Yehuda

From:	mjlu@sis.com.tw
Sent:	Tuesday, February 18, 1997 6:40 AM
To:	1394ohci-l@austin.ibm.com
Subject:	skip cases in IT DMA

Hi,all:

I have some more questions about IT DMA:
1.In Ch9 OHCI v0.91, cycle loss will make IT DMA skip packets. Are there any 
more cases that IT DMA will skip packets? If one context need to skip, 
whether other contexts need to do the same skip action to keep the 
synchronization between contexts?

2.In OHCI v0.91, page 122, the first 3 sentences, it describes that if 
transmit data read error happens before the header is placed in the output 
FIFO, HC will move on to the next descriptor block. Is this a skip case or 
HC just move on to the next descriptor block no matter what the skip address 
is ? And will this affect other contexts? Do other contexts need to do the 
same action?

3.How to handle FIFO underrun in IT DMA? Will it be a skip case ? Whether 
other contexts need to do the same skip action ?  

Thanks for your time and answer.


====================================================
Mei-Jiuan Lu
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
Phone:     886-35-774922 ext 4322
Fax:          886-35-790651
Email:      mjlu@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan
====================================================
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, February 18, 1997 8:16 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Wait control for bufferFill IR

I need to correct this.  I have mixed up versions of the spec.  Tag is only a 
filter and has nothing to do with the wait field.

Wait _can_ be used in buffer-fill mode.  Strictly speaking, the wait should be 
examined on each packet to see if it needs to be applied to the incoming 
packet.  This is of marginal use in buffer-fill mode but does allow some 
initial synchronization and can be used when the size of buffers is well 
known.

Sorry for the confusion.

David

DavidW@bangate.compaq.com Wrote:
| 
| Can be used to filter packets that don't have the correct tag or to provide 
| some initial synchronization.
| 
| David
| 
| cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| | 
| | Hi, all:
| | 
| | Will wait control be used for IR in bufferFill mode? If so, where
| | can it be used?
| | 
| | Thanks for your time and answer,
| | 
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | Chien-Yuh Lin
| | Design Engineer
| | Basic Technology Group
| | Silicon Intergrated Systems Corp.
| | Tel: 886-3-5774922 x 4326
| | Fax: 886-3-5778774
| | Email: cylin@sis.com.tw
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | 
| | 
| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, February 18, 1997 8:56 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Re: Posted Writes and SBP-2

An implication of the proposed ordering rules is that, when a write request is 
to a physical memory address but the access filter(s) causes that write to go 
to the AR request buffer, then the write may not be posted.  The ack_complete 
will have to be generated by SW and placed on the AT response queue.

For the ack_complete's that are sent for the mid-memory range, ordering, if 
required is provided by SW.  This is because both reads and writes of this 
space must be handled by SW. 

David

"Yehuda Peled" <PELED@HAIFASC3.HAIFA.IBM.COM> Wrote:
| 
| Comments embedded below.
| 
| >>Slightly revised rules:
| >>
| >> 1) There are no ordering relationships between asynchronous and 
isochronous
| >>packets.
| >>
| >> 2) Posted asynchronous write requests MAY pass any other asynchronous
| >>request in ANY inbound FIFO or DMA context.
| >>
| >> 3) Asynchronous requests in ANY inbound FIFO or DMA context SHALL NOT 
pass
| >>any posted asynchronous write request.
| 
| What about posted writes that are forwarded to the DMA context (not
| a Physical DMA). How can we insure that a physical read request will
| not pass those posted writes ?
| The problem is that there is no way to know when the device driver will
| process those posted write.
| 
| >>
| >>
| >>Regards,
| >>
| >>Peter
| >>
| >>
| 
| Regards,
|  Yehuda
| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, February 18, 1997 8:40 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Lost SBP-2 Status

EVERYONE WHO IS WORKING ON AN OHCI IMPLEMENTATION SHOULD READ THIS!!!

Some time ago, I was asked a question on the reflector (I can't remember the 
source) about why couldn't the HC simply throw away AR request packets if the 
buffer was full.  In other words, why is it necessary to keep track of the 
amount of available space in the AR request buffer.

The answer is below.  It is expected that when ack_complete is returned on a 
write that is going into the AR request buffer, that there is space available. 
 The only thing that should cause the packet to get lost is a host bus error.  
Therefor, if you are trying to reduce the number of FIFO's that are used for 
input, please be careful how you handle the AR request queue.  You can't 
simply let it run out and trash packets to which ack_complete was sent.

David


PJohansson@aol.com Wrote:
| 
| In a message dated 97-02-17 18:08:08 EST, DavidW@bangate.compaq.com writes:
| 
| << I'd like you to answer an SBP-2 question for me.  How does SBP-2  recover
| from 
|  a lost status packet (assume o-o-o completion.)  Can happen if status
| 'queue' 
|  in mid-memory (above physical, below CSR) where all  writes are 'posted'.
|  We 
|  can lose packets to this space without having any SW notification that 
|  something has gone wrong.
|   >>
| 
| The initiator error recovery might depend upon the ordered vs. nonordered
| behavior of the target.
| 
| If the target executes commands and reports completion status in order, it
| might happen that a "downstream" ORB reports successful completion status
| before a large time-out value at the initiator detected the missing status 
of
| an earlier, "upstream" ORB. This is an example where later status would heal
| the earlier lack of status. Not very likely, perhaps, but something that
| might happen.
| 
| The more likely case is when command execution is unordered or there is no
| providentially located "downstream" ORB whose status heals the omission:
| ABORT TASK SET. The target's task set may well be reduced to the isolated
| task that timed out by the time this is discovered, but even if not it's
| really the only option.
| 
| Your question assumes a host bus error, since OpenHCI guarantees that there
| was enough buffer space to receive the whole packet when the ack_complete 
was
| posted back to the target. When there is a host bus error, the chances are
| excellent (as John noted) that there's deep trouble in River City and a lost
| status packet may be the most inconsequential of problems next to the likely
| system crash.
| 
| Regards,
| 
| Peter
| 
| 
| 
From:	Eric W. Anderson [ewa@apple.com]
Sent:	Tuesday, February 18, 1997 9:51 AM
To:	Mei-Jiuan Lu; 1394ohci-l@austin.ibm.com
Subject:	Re: skip cases in IT DMA

>Hi,all:
>
>I have some more questions about IT DMA:
>1.In Ch9 OHCI v0.91, cycle loss will make IT DMA skip packets. Are there
any 
>more cases that IT DMA will skip packets? If one context need to skip, 
>whether other contexts need to do the same skip action to keep the 
>synchronization between contexts?

This is a complicated area, and we are working on some clarification.
I believe the answers will be that 1) Only cycle loss causes the ITDMA
to skip, 2) If there is a skip, all contexts will skip once.

>2.In OHCI v0.91, page 122, the first 3 sentences, it describes that if 
>transmit data read error happens before the header is placed in the output

>FIFO, HC will move on to the next descriptor block. Is this a skip case or

>HC just move on to the next descriptor block no matter what the skip
address 
>is ? And will this affect other contexts? Do other contexts need to do the

>same action?

Generally speaking, a host data error causes a lost packet, not a skip.
If the data read error resulted from a bogus DMA address, and we take
the skipBranch, and it loops back to the same descriptor, then we'll be
stuck in a loop where we get the same data read error over and over.

If the error also causes a FIFO underrun, however, then there can be a
skip *after* the lost packet, as described below.

>3.How to handle FIFO underrun in IT DMA? Will it be a skip case ? Whether 
>other contexts need to do the same skip action ?  

FIFO underrun causes the packet that underran to be lost (not skipped).
If there are more packets waiting for the same cycle, then all contexts
will skip, otherwise, no contexts will skip.  If all contexts skip, this
means that one of them will do both: lose the current packet, and then
skip the next packet.  All of the other contexts just skip one packet.

>Thanks for your time and answer.
>
>====================================================
>Mei-Jiuan Lu
>Engineer
>Basic Technology Group
>Silicon Integrated Systems Corp.
>Phone:     886-35-774922 ext 4322
>Fax:          886-35-790651
>Email:      mjlu@sis.com.tw
>Address: No 16, Creation Rd 1, 
>                 Science-based Industrial Park,
>                 Hsin Chu, Taiwan
>====================================================

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------



From:	John Nels Fuller
Sent:	Tuesday, February 18, 1997 10:16 AM
To:	'Yehuda Peled'; '1394OHCI-L@austin.ibm.com'
Cc:	'YENGEL@HAIFASC3.HAIFA.IBM.COM'
Subject:	RE: Posted Writes and SBP-2

In theory you are right, but in practice we expect that there will not
be overlap between requests from different nodes.  This means that the
reads that could possibly refer to an area that is awaiting s/w to
process a posted write will also be diverted to the DMA context instead
of being done by the physical response unit.

>-----Original Message-----
>From:	Yehuda Peled [SMTP:PELED@HAIFASC3.HAIFA.IBM.COM]
>Sent:	Tuesday, February 18, 1997 2:01 AM
>To:	1394OHCI-L@austin.ibm.com
>Cc:	YENGEL@HAIFASC3.HAIFA.IBM.COM
>Subject:	Re: Posted Writes and SBP-2
>
>Comments embedded below.
>
>>>Slightly revised rules:
>>>
>>> 1) There are no ordering relationships between asynchronous and
>>>isochronous
>>>packets.
>>>
>>> 2) Posted asynchronous write requests MAY pass any other asynchronous
>>>request in ANY inbound FIFO or DMA context.
>>>
>>> 3) Asynchronous requests in ANY inbound FIFO or DMA context SHALL NOT pass
>>>any posted asynchronous write request.
>
>What about posted writes that are forwarded to the DMA context (not
>a Physical DMA). How can we insure that a physical read request will
>not pass those posted writes ?
>The problem is that there is no way to know when the device driver will
>process those posted write.
>
>>>
>>>
>>>Regards,
>>>
>>>Peter
>>>
>>>
>
>Regards,
> Yehuda
From:	John Nels Fuller
Sent:	Tuesday, February 18, 1997 10:39 AM
To:	'DavidW@bangate.compaq.com'; '1394ohci-l@austin.ibm.com'
Subject:	RE: Re: Posted Writes and SBP-2

As I said in my earlier mail, I believe you can still post writes into
the AR request context because reads from that same node will also be
placed in the AR request context.

Please note, no device on 1394 is expected to just go out and make up
addresses it wants to read and write in host memory.  If one does then
you can bet that we will disable its physical access.  In general
devices talk to addresses that they have been told to talk to and no
where else.

>-----Original Message-----
>From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
>Sent:	Tuesday, February 18, 1997 8:56 AM
>To:	1394ohci-l@austin.ibm.com
>Subject:	re: Re: Posted Writes and SBP-2
>
>An implication of the proposed ordering rules is that, when a write request
>is 
>to a physical memory address but the access filter(s) causes that write to go
>to the AR request buffer, then the write may not be posted.  The ack_complete
>will have to be generated by SW and placed on the AT response queue.
>
>For the ack_complete's that are sent for the mid-memory range, ordering, if 
>required is provided by SW.  This is because both reads and writes of this 
>space must be handled by SW. 
>
>David
>
>"Yehuda Peled" <PELED@HAIFASC3.HAIFA.IBM.COM> Wrote:
>| 
>| Comments embedded below.
>| 
>| >>Slightly revised rules:
>| >>
>| >> 1) There are no ordering relationships between asynchronous and 
>isochronous
>| >>packets.
>| >>
>| >> 2) Posted asynchronous write requests MAY pass any other asynchronous
>| >>request in ANY inbound FIFO or DMA context.
>| >>
>| >> 3) Asynchronous requests in ANY inbound FIFO or DMA context SHALL NOT 
>pass
>| >>any posted asynchronous write request.
>| 
>| What about posted writes that are forwarded to the DMA context (not
>| a Physical DMA). How can we insure that a physical read request will
>| not pass those posted writes ?
>| The problem is that there is no way to know when the device driver will
>| process those posted write.
>| 
>| >>
>| >>
>| >>Regards,
>| >>
>| >>Peter
>| >>
>| >>
>| 
>| Regards,
>|  Yehuda
>| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, February 18, 1997 9:09 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: max_rec

Yehuda,

This 'simplification' is a bit hazardous.  It is likely that AT packets will 
need to be at least as large as allowed by s100 constraints (512 bytes?)  This 
is because we are likely to see a lot of interesting protocols come around 
that are going to need the full packet size.

Given the probable introduction of interoperability problems, I think we would 
not want to see such a constraint on AT packets become a part of the OHCI 
specification.

David


"Yehuda Peled (972-4-8296149)" <ypeled@VNET.IBM.COM> Wrote:
| 
| We are working on a 1394 Link controller design. To simplify the design
| we want to limit the size of the asynchronous transmitted packets.
| Is there a way to limit the asynchronous data packets length transmitted
| by a node ?
| The max_rec field can be used only to limit the length of inbound write
| request. I did not find a way to limit the data length requested by
| a read request packet.
| 
| According to the 1394 spec (section 8.3.2.5.4):
| "The max_rec field defines the maximum payload size of an asynchronous
| block write transaction addressed to the node...
| This max_rec field does not place any limits on the maximum payload
| size in asynchronous data packets, either requests or responses, that
| the node may transmit"
| 
| Regards,
|  Yehuda
| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, February 18, 1997 1:23 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: skip cases in IT DMA

Comments below.

David

mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
| 
| Hi,all:
| 
| I have some more questions about IT DMA:
| 1.In Ch9 OHCI v0.91, cycle loss will make IT DMA skip packets. Are there any 

| more cases that IT DMA will skip packets? If one context need to skip, 
| whether other contexts need to do the same skip action to keep the 
| synchronization between contexts?

Strictly speaking, IT DMA does not skip packets.  It takes the skip address of 
the descriptor block.  That address can point to the next descriptor (a true 
skip), to the same descriptor (send anyway), or anything else that makes sense 
including nothing (Z = 0).

The descripton will eventually explain that the HC will do the same thing for 
all contexts.  For each cycles worth of data, the HC determines whether to 
send data for all contexts or to skip (take the skip address) for all 
contexts.

| 
| 2.In OHCI v0.91, page 122, the first 3 sentences, it describes that if 
| transmit data read error happens before the header is placed in the output 
| FIFO, HC will move on to the next descriptor block. Is this a skip case or 
| HC just move on to the next descriptor block no matter what the skip address 

| is ? And will this affect other contexts? Do other contexts need to do the 
| same action?

If there is a read error on a data buffer, the HC treats the packet as if it 
had been sent (after setting the error condition in the descriptor.)  It does 
not take the skip address because the skip could point to the same packet 
which will likely fail again.  Also, the rule is to have the same treatment 
for all contexts in each cycle so if we attempted to send a packet, we are 
going to attempt to send packets for all contexts and not take the skip 
addresses.

| 
| 3.How to handle FIFO underrun in IT DMA? Will it be a skip case ? Whether 
| other contexts need to do the same skip action ?  

If FIFO underruns, the link side will discard the remaining data that might 
show up for the packet.  When the next packet showes up, if the link has not 
lost the connection, the packet will be sent.  If the connection has been 
lost, the packets will wait in the FIFO until the next cycle.  This will cause 
a cycle missing which will eventually lead to the host side taking the skip 
address for all contexts.  This is one of the not nice properties of the 
chosen scheme but we think/hope that this doesn't happen with enough frequency 
to matter. 

| 
| Thanks for your time and answer.
| 
| 
| ====================================================
| Mei-Jiuan Lu
| Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.
| Phone:     886-35-774922 ext 4322
| Fax:          886-35-790651
| Email:      mjlu@sis.com.tw
| Address: No 16, Creation Rd 1, 
|                  Science-based Industrial Park,
|                  Hsin Chu, Taiwan
| ====================================================
| 
| 
From:	cylin@sis.com.tw
Sent:	Monday, February 17, 1997 4:08 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Wait control for bufferFill IR

Hi, all:

Will wait control be used for IR in bufferFill mode? If so, where
can it be used?

Thanks for your time and answer,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	Eric W. Anderson [ewa@apple.com]
Sent:	Monday, February 17, 1997 10:40 AM
To:	Mei-Jiuan Lu; 1394ohci-l@austin.ibm.com
Subject:	Re: Questions about Isochronous Transmit DMA

>Hi,all:
>
>I have some questions about Isochronous Transmit DMA:
>1.In OHCI v0.91,page 92, the first sentence in the last paragraph: it 
>describes that "for each cycle, the IT DMA controller will complete one 
>descriptor block for each active IT DMA context". Does this restrict IT
DMA 
>controller should not do more than one descriptor block for each active IT

>DMA context in each cycle? And why set this restriction ?

1394-1995 requires that each isochronous channel can be transmited
at most once in each isochronous cycle.  If OHCI were to transmit two
packets on the same channel in the same cycle, this would not comply
with 1394-1995.  So we restrict the ITDMA to one packet/cycle/context.

Because software forms the packet headers in the ITDMA, it would be
possible to write a context program that transmits on multiple different
channels.  However, OHCI would have no way to tell when one cycle ends
and when the next one begins.  It would also be very difficult to keep
the four ITDMA contexts synchronized to the correct cycle.  To simplify
the hardware design, we require exactly one descriptor block per context
per cycle.  That descriptor block may transmit zero or one packets.
(Usually one)

We do not enforce that software must use one unique isochronous channel
for each context.  However, we do state that the intended use is one
channel per context.  If software really wants to do something unusual,
or something that does not comply with 1394-1995, this may be possible,
but we will not add extra design features to encourage (or prevent) this.

>2.Assume there are 4 IT contexts, should IT DMA controller keep the
transmit 
>data the same order in every cycle ? For example: A,B,C,D are the 4 
>contexts, in cycle 2000, data order in DATA FIFO is A->B->C->D, so the iso

>packet in 1394 bus will be A->B->C->D, should HC maintain the same order
in 
>next cycle?

1394-1995 does not require any specific ordering on the channels within
each isochronous cycle.  The order in which transmitting nodes win
isochronous arbitration may vary from cycle to cycle, and the order of
packets sent by any single node may also vary from cycle to cycle.  So
the ITDMA could send packets for each cycle in any order, and comply
with 1394-1995.

OHCI 0.91 does not specify that the ITDMA must process contexts in
fixed order.  It is possible that some optimization might be obtained
by sending packets out of order, however, I imagine that this would
be too complex to be cost-effective.  We could leave this up to
implementors.  Or, we could specify in-order processing, so that
software has one less variable to worry about.  (My preference is
to require in-order processing).

In your example, A, B, C, and D are the four OHCI ITDMA contexts, where
"A" is ITDMA Context 0, "B" is ITDMA Context 1, etc.

>        cycle                   2000                             2001     
  
>                   
>        data order            A->B->C->D                A->B->C->D(???)
>2.1 If it is required for IT DMA controller to maintain the data order, in

>the following example, which one is correct. in cycle 2000,only context 
>A,B,D are enabled, in cycle 2001,context A,B,C,D are enabled.
>case1
>          cycle           2000                  2001
>2002         
>        data order    A->B->D       A->B->C->D       A->B->C->D
>case2
>         cycle            2000                   2001                  
2002
>
>        data order    A->B->D       C->A->B->D        C-> A->B->D
>case3 
>        cycle             2000                   2001                  
2002
>
>        data order    A->B->D        A->B->D->C        A->B->D->C
>
>Which case will be correct?

I believe case 1 is consistent with what I wrote above, and is also
the most natural hardware implementation.


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------



From:	PJohansson@aol.com
Sent:	Tuesday, February 18, 1997 8:51 PM
To:	PELED@haifasc3.haifa.ibm.com; 1394OHCI-L@austin.ibm.com
Cc:	YENGEL@haifasc3.haifa.ibm.com
Subject:	Re: Posted Writes and SBP-2

In a message dated 97-02-18 03:20:06 EST, PELED@HAIFASC3.HAIFA.IBM.COM
(Yehuda Peled) writes:

<< What about posted writes that are forwarded to the DMA context (not
 a Physical DMA). How can we insure that a physical read request will
 not pass those posted writes ?
 The problem is that there is no way to know when the device driver will
 process those posted write.
  >>

A thorny problem, Yehuda.

If physical read and physical write capabilities are enabled or disabled in
tandem perhaps we define away the problem. But maybe this is not satisfactory
for everyone.

If physical reads can be enabled while physical writes are disabled we would
have to invent a synchronization mechanism between the physical read DMA
context and the software that carries out the posted writes to the lower 4 GB
of memory.

If the physical read DMA handles one request at a time it could be made
"busy" by the OpenHCI hardware any time an ack_complete was sent for a posted
write. Software could subsequently reenable the physical read DMA after
enqueing a response packet for the posted write. Since no physical reads
could arrive while the posted write was in progress they would be unable to
pass it.

My implementation preference would be that physical read and physical write
DMA are a package deal that are turned on and off together.

Regards,

Peter

From:	DavidW@bangate.compaq.com
Sent:	Tuesday, February 18, 1997 3:54 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: RE: Re: Posted Writes and SBP-2

John,

I think there is a hole. If node A does a write that gets posted.  Node A 
thinks write is done.  So, node A notifies node B to go get the results of the 
write which are now available in the host.  Node B, which has access 
privileges, comes and reads the data which is stale because the posted write 
that ended up in the AR request queue, hasn't been processed by software.

Question about your statement in paragraph two.  If a 1394 device with 
privileges accesses something that it isn't supposed to, how would you know?

David

John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
| 
| As I said in my earlier mail, I believe you can still post writes into
| the AR request context because reads from that same node will also be
| placed in the AR request context.
| 
| Please note, no device on 1394 is expected to just go out and make up
| addresses it wants to read and write in host memory.  If one does then
| you can bet that we will disable its physical access.  In general
| devices talk to addresses that they have been told to talk to and no
| where else.
| 
| >-----Original Message-----
| >From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
| >Sent:	Tuesday, February 18, 1997 8:56 AM
| >To:	1394ohci-l@austin.ibm.com
| >Subject:	re: Re: Posted Writes and SBP-2
| >
| >An implication of the proposed ordering rules is that, when a write request
| >is 
| >to a physical memory address but the access filter(s) causes that write to 
go
| >to the AR request buffer, then the write may not be posted.  The 
ack_complete
| >will have to be generated by SW and placed on the AT response queue.
| >
| >For the ack_complete's that are sent for the mid-memory range, ordering, if 

| >required is provided by SW.  This is because both reads and writes of this 
| >space must be handled by SW. 
| >
| >David
| >
| >"Yehuda Peled" <PELED@HAIFASC3.HAIFA.IBM.COM> Wrote:
| >| 
| >| Comments embedded below.
| >| 
| >| >>Slightly revised rules:
| >| >>
| >| >> 1) There are no ordering relationships between asynchronous and 
| >isochronous
| >| >>packets.
| >| >>
| >| >> 2) Posted asynchronous write requests MAY pass any other asynchronous
| >| >>request in ANY inbound FIFO or DMA context.
| >| >>
| >| >> 3) Asynchronous requests in ANY inbound FIFO or DMA context SHALL NOT 
| >pass
| >| >>any posted asynchronous write request.
| >| 
| >| What about posted writes that are forwarded to the DMA context (not
| >| a Physical DMA). How can we insure that a physical read request will
| >| not pass those posted writes ?
| >| The problem is that there is no way to know when the device driver will
| >| process those posted write.
| >| 
| >| >>
| >| >>
| >| >>Regards,
| >| >>
| >| >>Peter
| >| >>
| >| >>
| >| 
| >| Regards,
| >|  Yehuda
| >| 
| 
From:	Yehuda Peled (972-4-8296149) [ypeled@VNET.IBM.COM]
Sent:	Wednesday, February 19, 1997 1:19 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: max_rec

David,
The 'simplification' is not for an HCI design, but for a simple 1394
target design.
I agree that an HCI device must support the maximum packet size.

Yehuda

"DavidW@bangate.compaq.com" Wrote:

|Yehuda,
|
|This 'simplification' is a bit hazardous.  It is likely that AT packets will
|need to be at least as large as allowed by s100 constraints (512 bytes?)  This
|is because we are likely to see a lot of interesting protocols come around
|that are going to need the full packet size.
|
|Given the probable introduction of interoperability problems, I think we would
|not want to see such a constraint on AT packets become a part of the OHCI
|specification.
|
|David
|
From:	mjlu@sis.com.tw
Sent:	Wednesday, February 19, 1997 5:24 AM
To:	1394ohci-l@austin.ibm.com
Subject:	More questions about IT DMA

Hi,all:

Thanks Eric W.Anderson and David Wooten's answers about how many descriptor 
blocks which  IT DMA can process for each cycle. But I still get a little 
confused about your answers. Would u mind to answer me more clear ? 
Thanks a lot !!

The questions are:
1.In Eric W.Anderson's answer mentions that "we restrict the ITDMA to one 
packet/cycle/context" and "To simplify the hardware design, we require 
exactly one descriptor block per context per cycle". What does the "cycle" 
mean ? Does it mean "an isochronous cycle on 1394 bus" or "a cycle which IT 
DMA tranmission all contexts data to FIFO" ? 
For example: 4(A,B,C,D) IT contexts, "a cycle which IT DMA tranmission all 
contexts data to FIFO" means A,B,C,D are serviced once in a time period, 
thus for an isochronous cycle on 1394 bus, IT DMA may transmit data into 
FIFO in the order of A->B->C->D->A->B->C->D, which are  worth of 2 
isochronous cycle data.

2.In David Wooten's answer mentions that does not set the restriction on 
only one descriptor blocks may be processed during any particular bus cycle. 
This is really different with what Eric W.Anderson's answers if the "cycle" 
in Eric W.Anderson's answer means an isochronous cycle. This is what confuse 
me.

3.How can hardware decide  how many contexts  may transmit in an 
isochronous cycle, thus to decide how many contexts IT DMA should process in 
an isochronous cycle, since software may set the run bit of each context in 
a sequence not at the same time ? If the synchronization between contexts is 
important, can software take all of the responsibility to make sure this? 
For example: A,B,C need to start to  trasmit packets at the same isochronous 
cycle, then software set the run bit of the 3 contexts in a sequence but 
also set the wait bit to wait for a long enough time for completion of 3 
command prefetch thus they can fill FIFO at the same isochronous cycle then 
been transmitted at the isochronous cycle. If the wait bit is not set, the 
synchronization between contexts is hard to maintain by hardware. Is there 
any other method can reach the same goal or the synchronization is not 
promised by OHCI ?


====================================================
Mei-Jiuan Lu
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
Phone:     886-35-774922 ext 4322
Fax:          886-35-790651
Email:      mjlu@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan
====================================================
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, February 19, 1997 6:18 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: skip cases in IT DMA

In an earlier email, Mei-Jiuan Lu wrote:


| 
| 3.How to handle FIFO underrun in IT DMA? Will it be a skip case ? Whether 
| other contexts need to do the same skip action ?  
| 


By now, you probably have seen at least two contradictory answers for this, 
one from Eric and one from me.  We are working on resolving our differences.  
Please stand by.


David
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, February 19, 1997 8:50 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: More questions about IT DMA

I believe that Eric and I actually said the same thing (this time.)  Let me 
try again.

When we say "in a cycle" we mean two things.  First, a cycle means a 1394 
cycle.  They are delimited by cycle_start packets on 1394 bus.  Second, when 
talking about ITDMA, a cycle means all of the data that is to be sent during a 
1394 cycle.

Now, because the host side of the IT FIFO is working ahead of the link side of 
the FIFO, data for a 1394 cycle can be put into the FIFO long before it is 
sent on the bus.  This creates a time decoupling of the input of the FIFO from 
the output of the FIFO. So when we talk about a cycle of data on the host side 
of the FIFO, we mean the data that, taken together, will be sent on the 1394 
bus during a single 1394 bus cycle.  The time between when data is put into 
the FIFO and when it is taken out of the FIFO can be as long as 2, 1394 bus 
cycles.

As the host side does it's processing, it processes each active context (all 
with 'run' set) in some arbitrary order.  For each context it processes, it 
fetches exactly one descriptor block which describes exactly one packet that 
is to be sent for that context in a 1394 cycle.  When all of the contexts have 
been processed, the host side puts a delimiter in the FIFO to let the link 
side know that the end of a cycle's worth of data has been reached.

When a cycle start appears on the 1394 bus, the link starts taking packets out 
of the IT FIFO.  It takes data out and send it on the bus until it reaches the 
end of cycle delimiter in the FIFO.  It then stops and waits for the next 
cycle start on the 1394 bus.

Since the host side and the link side are not time synchronized, the host side 
must have its own cycle timer.  This keeps track of the cycle number for which 
data is being put into the FIFO.  It is _not_ the same cycle timer that the 
link side uses.  When the chip is initialized, the timers are set to the same 
value and then the host side can start putting things in the FIFO.  It has 
been suggested that the first thing that the host side should do is to place 
two end of cycle delimiters in the FIFO to get some time to work.  It then 
starts its normal processing.  When difference between host side cycle  time 
and link side cycle time is less than two, the host can start putting things 
into the FIFO.

If precise synchronization of the start time of a context or contexts is 
important, then those contexts can be started with the desired starting cycle 
number in ContextControl.cycleMatch.  When the host side starts processing 
data that is to be sent in the selected cycle, the host side cycle timer will 
match ContextControl.cycleMatch and the first descriptor for that context will 
get processed.  If several contexts are programmed with the same cycleMatch, 
they will all start on the same cycle.  This is the only way to synchronize 
the start of two or more contexts.

Setting the run bit without enabling the cycleMatch will cause the context to 
start the next time the controller accesses the context.  It might be as it is 
processing for the current 'cycle' or not until the next 'cycle'.

There is no 'wait' bit for IT.

I hope this clears up the confusion.

David

mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
| 
| Hi,all:
| 
| Thanks Eric W.Anderson and David Wooten's answers about how many descriptor 
| blocks which  IT DMA can process for each cycle. But I still get a little 
| confused about your answers. Would u mind to answer me more clear ? 
| Thanks a lot !!
| 
| The questions are:
| 1.In Eric W.Anderson's answer mentions that "we restrict the ITDMA to one 
| packet/cycle/context" and "To simplify the hardware design, we require 
| exactly one descriptor block per context per cycle". What does the "cycle" 
| mean ? Does it mean "an isochronous cycle on 1394 bus" or "a cycle which IT 
| DMA tranmission all contexts data to FIFO" ? 
| For example: 4(A,B,C,D) IT contexts, "a cycle which IT DMA tranmission all 
| contexts data to FIFO" means A,B,C,D are serviced once in a time period, 
| thus for an isochronous cycle on 1394 bus, IT DMA may transmit data into 
| FIFO in the order of A->B->C->D->A->B->C->D, which are  worth of 2 
| isochronous cycle data.
| 
| 2.In David Wooten's answer mentions that does not set the restriction on 
| only one descriptor blocks may be processed during any particular bus cycle. 

| This is really different with what Eric W.Anderson's answers if the "cycle" 
| in Eric W.Anderson's answer means an isochronous cycle. This is what confuse 

| me.
| 
| 3.How can hardware decide  how many contexts  may transmit in an 
| isochronous cycle, thus to decide how many contexts IT DMA should process in 

| an isochronous cycle, since software may set the run bit of each context in 
| a sequence not at the same time ? If the synchronization between contexts is 

| important, can software take all of the responsibility to make sure this? 
| For example: A,B,C need to start to  trasmit packets at the same isochronous 

| cycle, then software set the run bit of the 3 contexts in a sequence but 
| also set the wait bit to wait for a long enough time for completion of 3 
| command prefetch thus they can fill FIFO at the same isochronous cycle then 
| been transmitted at the isochronous cycle. If the wait bit is not set, the 
| synchronization between contexts is hard to maintain by hardware. Is there 
| any other method can reach the same goal or the synchronization is not 
| promised by OHCI ?
| 
| 
| ====================================================
| Mei-Jiuan Lu
| Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.
| Phone:     886-35-774922 ext 4322
| Fax:          886-35-790651
| Email:      mjlu@sis.com.tw
| Address: No 16, Creation Rd 1, 
|                  Science-based Industrial Park,
|                  Hsin Chu, Taiwan
| ====================================================
| 
| 
From:	mis@aluxs.micro.lucent.com
Sent:	Wednesday, February 19, 1997 9:20 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: More questions about IT DMA

DavidW@bangate.compaq.com wrote:
 
> Since the host side and the link side are not time synchronized, the host side 
> must have its own cycle timer.  This keeps track of the cycle number for which 
> data is being put into the FIFO.  It is _not_ the same cycle timer that the 
> link side uses.  When the chip is initialized, the timers are set to the same 
> value and then the host side can start putting things in the FIFO.  It has 
> been suggested that the first thing that the host side should do is to place 
> two end of cycle delimiters in the FIFO to get some time to work.  It then 
> starts its normal processing.  When difference between host side cycle  time 
> and link side cycle time is less than two, the host can start putting things 
> into the FIFO.

I guess David meant to say that the host side has a cycle counter (nee timer). I read an implication that host side is going to increment this counter after it puts a cycle delimiter into IT FIFO. Correct?

Also, is this behaviour mostly hypothetical anyway because it assumes a _large_ sized IT FIFO to accomodate 2 cycles worth of IT packets. I agree that a separate cycle_counter is probably useful, but in reality it will mostly have the same value as link side cycle_timer.

Mike
From:	John Nels Fuller
Sent:	Wednesday, February 19, 1997 9:35 AM
To:	'DavidW@bangate.compaq.com'; '1394ohci-l@austin.ibm.com'
Subject:	RE: RE: Re: Posted Writes and SBP-2

David,

Can you give me an example of a protocol that involves 3 nodes?  I know
of none except for isochronous which is not a problem.  Although a case
is allowed for in SBP-2 to have a device transfer data into/from a node
that is not the initiator (Node A being the device, Node B being the
initiator, and Node C being the recipient of the data), I can't imagine
this being done without Node B forwarding Node A's completion notice to
Node C such that it goes through the AR DMA instead of the physical DMA.

As for finding out which devices do things they shouldn't, this won't be
done on the fly in the user's environment.  But we will become aware of
those devices through several channels, for example: logo qualification
tests on a device could run in untested mode and verify all
transactions; field reports of system failures can lead to a particular
device; and certain classes of devices will simply never be trusted.

jnf

>-----Original Message-----
>From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
>Sent:	Tuesday, February 18, 1997 3:54 PM
>To:	1394ohci-l@austin.ibm.com
>Subject:	re: RE: Re: Posted Writes and SBP-2
>
>John,
>
>I think there is a hole. If node A does a write that gets posted.  Node A 
>thinks write is done.  So, node A notifies node B to go get the results of
>the 
>write which are now available in the host.  Node B, which has access 
>privileges, comes and reads the data which is stale because the posted write 
>that ended up in the AR request queue, hasn't been processed by software.
>
>Question about your statement in paragraph two.  If a 1394 device with 
>privileges accesses something that it isn't supposed to, how would you know?
>
>David
>
>John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
>| 
>| As I said in my earlier mail, I believe you can still post writes into
>| the AR request context because reads from that same node will also be
>| placed in the AR request context.
>| 
>| Please note, no device on 1394 is expected to just go out and make up
>| addresses it wants to read and write in host memory.  If one does then
>| you can bet that we will disable its physical access.  In general
>| devices talk to addresses that they have been told to talk to and no
>| where else.
>| 
>| >-----Original Message-----
>| >From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
>| >Sent:	Tuesday, February 18, 1997 8:56 AM
>| >To:	1394ohci-l@austin.ibm.com
>| >Subject:	re: Re: Posted Writes and SBP-2
>| >
>| >An implication of the proposed ordering rules is that, when a write
>request
>| >is 
>| >to a physical memory address but the access filter(s) causes that write to
>go
>| >to the AR request buffer, then the write may not be posted.  The 
>ack_complete
>| >will have to be generated by SW and placed on the AT response queue.
>| >
>| >For the ack_complete's that are sent for the mid-memory range, ordering,
>if 
>
>| >required is provided by SW.  This is because both reads and writes of this
>| >space must be handled by SW. 
>| >
>| >David
>| >
>| >"Yehuda Peled" <PELED@HAIFASC3.HAIFA.IBM.COM> Wrote:
>| >| 
>| >| Comments embedded below.
>| >| 
>| >| >>Slightly revised rules:
>| >| >>
>| >| >> 1) There are no ordering relationships between asynchronous and 
>| >isochronous
>| >| >>packets.
>| >| >>
>| >| >> 2) Posted asynchronous write requests MAY pass any other asynchronous
>| >| >>request in ANY inbound FIFO or DMA context.
>| >| >>
>| >| >> 3) Asynchronous requests in ANY inbound FIFO or DMA context SHALL NOT
>| >pass
>| >| >>any posted asynchronous write request.
>| >| 
>| >| What about posted writes that are forwarded to the DMA context (not
>| >| a Physical DMA). How can we insure that a physical read request will
>| >| not pass those posted writes ?
>| >| The problem is that there is no way to know when the device driver will
>| >| process those posted write.
>| >| 
>| >| >>
>| >| >>
>| >| >>Regards,
>| >| >>
>| >| >>Peter
>| >| >>
>| >| >>
>| >| 
>| >| Regards,
>| >|  Yehuda
>| >| 
>| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, February 19, 1997 10:34 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: RE: RE: Re: Posted Writes and SBP-2

John,

Since you asked for an example and not a _good_ example, here goes...

Suppose we are doing a copy from one device to another.  Furthermore, suppose 
that neither of these devices has a lot of local memory so they are using host 
memory as a buffer.  Device A finishes a transfer to system memory and then 
tells device B that the data is now available and it can complete the copy.  
If the host posts the write and returns ack_complete to device A then device A 
can inform device B that the data is available.  So, device B goes to get the 
data and ...

Now, this is, admittedly, not a good example.  It is, however, an example of a 
protocol that is not otherwise precluded by serial bus.  I don't necessarily 
mind disallowing such protocols but I'm not sure that that is something we 
would take on in the context of OHCI (seems like something that one would do 
in the 1394A context.)

David

John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
| 
| David,
| 
| Can you give me an example of a protocol that involves 3 nodes?  I know
| of none except for isochronous which is not a problem.  Although a case
| is allowed for in SBP-2 to have a device transfer data into/from a node
| that is not the initiator (Node A being the device, Node B being the
| initiator, and Node C being the recipient of the data), I can't imagine
| this being done without Node B forwarding Node A's completion notice to
| Node C such that it goes through the AR DMA instead of the physical DMA.
| 
| As for finding out which devices do things they shouldn't, this won't be
| done on the fly in the user's environment.  But we will become aware of
| those devices through several channels, for example: logo qualification
| tests on a device could run in untested mode and verify all
| transactions; field reports of system failures can lead to a particular
| device; and certain classes of devices will simply never be trusted.
| 
| jnf
| 
| >-----Original Message-----
| >From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
| >Sent:	Tuesday, February 18, 1997 3:54 PM
| >To:	1394ohci-l@austin.ibm.com
| >Subject:	re: RE: Re: Posted Writes and SBP-2
| >
| >John,
| >
| >I think there is a hole. If node A does a write that gets posted.  Node A 
| >thinks write is done.  So, node A notifies node B to go get the results of
| >the 
| >write which are now available in the host.  Node B, which has access 
| >privileges, comes and reads the data which is stale because the posted 
write 
| >that ended up in the AR request queue, hasn't been processed by software.
| >
| >Question about your statement in paragraph two.  If a 1394 device with 
| >privileges accesses something that it isn't supposed to, how would you 
know?
| >
| >David
| >
| >John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
| >| 
| >| As I said in my earlier mail, I believe you can still post writes into
| >| the AR request context because reads from that same node will also be
| >| placed in the AR request context.
| >| 
| >| Please note, no device on 1394 is expected to just go out and make up
| >| addresses it wants to read and write in host memory.  If one does then
| >| you can bet that we will disable its physical access.  In general
| >| devices talk to addresses that they have been told to talk to and no
| >| where else.
| >| 
| >| >-----Original Message-----
| >| >From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
| >| >Sent:	Tuesday, February 18, 1997 8:56 AM
| >| >To:	1394ohci-l@austin.ibm.com
| >| >Subject:	re: Re: Posted Writes and SBP-2
| >| >
| >| >An implication of the proposed ordering rules is that, when a write
| >request
| >| >is 
| >| >to a physical memory address but the access filter(s) causes that write 
to
| >go
| >| >to the AR request buffer, then the write may not be posted.  The 
| >ack_complete
| >| >will have to be generated by SW and placed on the AT response queue.
| >| >
| >| >For the ack_complete's that are sent for the mid-memory range, ordering,
| >if 
| >

| >| >required is provided by SW.  This is because both reads and writes of 
this
| >| >space must be handled by SW. 
| >| >
| >| >David
| >| >
| >| >"Yehuda Peled" <PELED@HAIFASC3.HAIFA.IBM.COM> Wrote:
| >| >| 
| >| >| Comments embedded below.
| >| >| 
| >| >| >>Slightly revised rules:
| >| >| >>
| >| >| >> 1) There are no ordering relationships between asynchronous and 
| >| >isochronous
| >| >| >>packets.
| >| >| >>
| >| >| >> 2) Posted asynchronous write requests MAY pass any other 
asynchronous
| >| >| >>request in ANY inbound FIFO or DMA context.
| >| >| >>
| >| >| >> 3) Asynchronous requests in ANY inbound FIFO or DMA context SHALL 
NOT
| >| >pass
| >| >| >>any posted asynchronous write request.
| >| >| 
| >| >| What about posted writes that are forwarded to the DMA context (not
| >| >| a Physical DMA). How can we insure that a physical read request will
| >| >| not pass those posted writes ?
| >| >| The problem is that there is no way to know when the device driver 
will
| >| >| process those posted write.
| >| >| 
| >| >| >>
| >| >| >>
| >| >| >>Regards,
| >| >| >>
| >| >| >>Peter
| >| >| >>
| >| >| >>
| >| >| 
| >| >| Regards,
| >| >|  Yehuda
| >| >| 
| >| 
| 
From:	Eric W. Anderson [ewa@apple.com]
Sent:	Wednesday, February 19, 1997 10:19 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: More questions about IT DMA

Yes, David and I said the same thing, and we agree on how it works.
My explanation may have been confusing if you thought I meant that
the DMA side was working in "real" cycles.  As David explained, the
DMA side works ahead of schedule.  It is possible the the DMA could
"process" (load into the FIFO) two whole cycle's worth of packets
during one actual 1394 cycle, but those packets would not be
*transmitted* during one 1394 cycle.  They would be transmitted in
two 1394 cycles.

We are working on additional documentation that will clarify how the
DMA side and the Link side keep their independent clocks, and how they
coordinate the processing of a cycle loss.  This is obviously a
difficult subject to describe, so it may take us some time to get it
right.

To reiterate what David said, for each cycle's worth of packets, the
DMA will either skip all of the packets, or put all of the packets
into the FIFO.  But this work might take place during a previous cycle,
or during two previous cycles, because the DMA is working ahead.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------

>I believe that Eric and I actually said the same thing (this time.)  Let
me 
>try again.
>
>When we say "in a cycle" we mean two things.  First, a cycle means a 1394 
>cycle.  They are delimited by cycle_start packets on 1394 bus.  Second,
when 
>talking about ITDMA, a cycle means all of the data that is to be sent
during
>a 
>1394 cycle.
>
>Now, because the host side of the IT FIFO is working ahead of the link
side
>of 
>the FIFO, data for a 1394 cycle can be put into the FIFO long before it is

>sent on the bus.  This creates a time decoupling of the input of the FIFO
>from 
>the output of the FIFO. So when we talk about a cycle of data on the host
>side 
>of the FIFO, we mean the data that, taken together, will be sent on the
1394 
>bus during a single 1394 bus cycle.  The time between when data is put
into 
>the FIFO and when it is taken out of the FIFO can be as long as 2, 1394
bus 
>cycles.
>
>As the host side does it's processing, it processes each active context
(all 
>with 'run' set) in some arbitrary order.  For each context it processes,
it 
>fetches exactly one descriptor block which describes exactly one packet
that 
>is to be sent for that context in a 1394 cycle.  When all of the contexts
>have 
>been processed, the host side puts a delimiter in the FIFO to let the link

>side know that the end of a cycle's worth of data has been reached.
>
>When a cycle start appears on the 1394 bus, the link starts taking packets
>out 
>of the IT FIFO.  It takes data out and send it on the bus until it reaches
>the 
>end of cycle delimiter in the FIFO.  It then stops and waits for the next 
>cycle start on the 1394 bus.
>
>Since the host side and the link side are not time synchronized, the host
>side 
>must have its own cycle timer.  This keeps track of the cycle number for
>which 
>data is being put into the FIFO.  It is _not_ the same cycle timer that
the 
>link side uses.  When the chip is initialized, the timers are set to the
>same 
>value and then the host side can start putting things in the FIFO.  It has

>been suggested that the first thing that the host side should do is to
place 
>two end of cycle delimiters in the FIFO to get some time to work.  It then

>starts its normal processing.  When difference between host side cycle 
time 
>and link side cycle time is less than two, the host can start putting
things 
>into the FIFO.
>
>If precise synchronization of the start time of a context or contexts is 
>important, then those contexts can be started with the desired starting
>cycle 
>number in ContextControl.cycleMatch.  When the host side starts processing

>data that is to be sent in the selected cycle, the host side cycle timer
>will 
>match ContextControl.cycleMatch and the first descriptor for that context
>will 
>get processed.  If several contexts are programmed with the same
cycleMatch, 
>they will all start on the same cycle.  This is the only way to
synchronize 
>the start of two or more contexts.
>
>Setting the run bit without enabling the cycleMatch will cause the context
>to 
>start the next time the controller accesses the context.  It might be as
it
>is 
>processing for the current 'cycle' or not until the next 'cycle'.
>
>There is no 'wait' bit for IT.
>
>I hope this clears up the confusion.
>
>David
>
>mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
>| 
>| Hi,all:
>| 
>| Thanks Eric W.Anderson and David Wooten's answers about how many
>descriptor 
>| blocks which  IT DMA can process for each cycle. But I still get a
little 
>| confused about your answers. Would u mind to answer me more clear ? 
>| Thanks a lot !!
>| 
>| The questions are:
>| 1.In Eric W.Anderson's answer mentions that "we restrict the ITDMA to
one 
>| packet/cycle/context" and "To simplify the hardware design, we require 
>| exactly one descriptor block per context per cycle". What does the
"cycle" 
>| mean ? Does it mean "an isochronous cycle on 1394 bus" or "a cycle which
>IT 
>| DMA tranmission all contexts data to FIFO" ? 
>| For example: 4(A,B,C,D) IT contexts, "a cycle which IT DMA tranmission
all 
>| contexts data to FIFO" means A,B,C,D are serviced once in a time period,

>| thus for an isochronous cycle on 1394 bus, IT DMA may transmit data into

>| FIFO in the order of A->B->C->D->A->B->C->D, which are  worth of 2 
>| isochronous cycle data.
>| 
>| 2.In David Wooten's answer mentions that does not set the restriction on

>| only one descriptor blocks may be processed during any particular bus
>cycle. 
>
>| This is really different with what Eric W.Anderson's answers if the
>"cycle" 
>| in Eric W.Anderson's answer means an isochronous cycle. This is what
>confuse 
>
>| me.
>| 
>| 3.How can hardware decide  how many contexts  may transmit in an 
>| isochronous cycle, thus to decide how many contexts IT DMA should
process
>in 
>
>| an isochronous cycle, since software may set the run bit of each context
>in 
>| a sequence not at the same time ? If the synchronization between
contexts
>is 
>
>| important, can software take all of the responsibility to make sure
this? 
>| For example: A,B,C need to start to  trasmit packets at the same
>isochronous 
>
>| cycle, then software set the run bit of the 3 contexts in a sequence but

>| also set the wait bit to wait for a long enough time for completion of 3

>| command prefetch thus they can fill FIFO at the same isochronous cycle
>then 
>| been transmitted at the isochronous cycle. If the wait bit is not set,
the 
>| synchronization between contexts is hard to maintain by hardware. Is
there 
>| any other method can reach the same goal or the synchronization is not 
>| promised by OHCI ?
>| 
>| 
>| ====================================================
>| Mei-Jiuan Lu
>| Engineer
>| Basic Technology Group
>| Silicon Integrated Systems Corp.
>| Phone:     886-35-774922 ext 4322
>| Fax:          886-35-790651
>| Email:      mjlu@sis.com.tw
>| Address: No 16, Creation Rd 1, 
>|                  Science-based Industrial Park,
>|                  Hsin Chu, Taiwan
>| ====================================================
>| 
>| 
>




From:	John Nels Fuller
Sent:	Wednesday, February 19, 1997 11:21 AM
To:	'DavidW@bangate.compaq.com'; '1394ohci-l@austin.ibm.com'
Subject:	RE: RE: RE: Re: Posted Writes and SBP-2

David,

Well, you said it wasn't a _good_ example.  I'm not trying to say that
such things are not possible in theory, just that I find it hard to
imagine anyone trying to define a protocol to do something like this,
much less an OS trying to use it.  It seems a shame for OHCI to
sacrifice performance or become more complex just to support something
that will probably never be used; especially when there is a software
workaround, i.e. just make sure all nodes involved in the protocol have
the same physical access characteristics (enabled or disabled).

jnf

>-----Original Message-----
>From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
>Sent:	Wednesday, February 19, 1997 10:34 AM
>To:	1394ohci-l@austin.ibm.com
>Subject:	re: RE: RE: Re: Posted Writes and SBP-2
>
>John,
>
>Since you asked for an example and not a _good_ example, here goes...
>
>Suppose we are doing a copy from one device to another.  Furthermore, suppose
>that neither of these devices has a lot of local memory so they are using
>host 
>memory as a buffer.  Device A finishes a transfer to system memory and then 
>tells device B that the data is now available and it can complete the copy.  
>If the host posts the write and returns ack_complete to device A then device
>A 
>can inform device B that the data is available.  So, device B goes to get the
>data and ...
>
>Now, this is, admittedly, not a good example.  It is, however, an example of
>a 
>protocol that is not otherwise precluded by serial bus.  I don't necessarily 
>mind disallowing such protocols but I'm not sure that that is something we 
>would take on in the context of OHCI (seems like something that one would do 
>in the 1394A context.)
>
>David
>
>John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
>| 
>| David,
>| 
>| Can you give me an example of a protocol that involves 3 nodes?  I know
>| of none except for isochronous which is not a problem.  Although a case
>| is allowed for in SBP-2 to have a device transfer data into/from a node
>| that is not the initiator (Node A being the device, Node B being the
>| initiator, and Node C being the recipient of the data), I can't imagine
>| this being done without Node B forwarding Node A's completion notice to
>| Node C such that it goes through the AR DMA instead of the physical DMA.
>| 
>| As for finding out which devices do things they shouldn't, this won't be
>| done on the fly in the user's environment.  But we will become aware of
>| those devices through several channels, for example: logo qualification
>| tests on a device could run in untested mode and verify all
>| transactions; field reports of system failures can lead to a particular
>| device; and certain classes of devices will simply never be trusted.
>| 
>| jnf
>| 
>| >-----Original Message-----
>| >From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
>| >Sent:	Tuesday, February 18, 1997 3:54 PM
>| >To:	1394ohci-l@austin.ibm.com
>| >Subject:	re: RE: Re: Posted Writes and SBP-2
>| >
>| >John,
>| >
>| >I think there is a hole. If node A does a write that gets posted.  Node A 
>| >thinks write is done.  So, node A notifies node B to go get the results of
>| >the 
>| >write which are now available in the host.  Node B, which has access 
>| >privileges, comes and reads the data which is stale because the posted 
>write 
>| >that ended up in the AR request queue, hasn't been processed by software.
>| >
>| >Question about your statement in paragraph two.  If a 1394 device with 
>| >privileges accesses something that it isn't supposed to, how would you 
>know?
>| >
>| >David
>| >
>| >John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
>| >| 
>| >| As I said in my earlier mail, I believe you can still post writes into
>| >| the AR request context because reads from that same node will also be
>| >| placed in the AR request context.
>| >| 
>| >| Please note, no device on 1394 is expected to just go out and make up
>| >| addresses it wants to read and write in host memory.  If one does then
>| >| you can bet that we will disable its physical access.  In general
>| >| devices talk to addresses that they have been told to talk to and no
>| >| where else.
>| >| 
>| >| >-----Original Message-----
>| >| >From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
>| >| >Sent:	Tuesday, February 18, 1997 8:56 AM
>| >| >To:	1394ohci-l@austin.ibm.com
>| >| >Subject:	re: Re: Posted Writes and SBP-2
>| >| >
>| >| >An implication of the proposed ordering rules is that, when a write
>| >request
>| >| >is 
>| >| >to a physical memory address but the access filter(s) causes that write
>to
>| >go
>| >| >to the AR request buffer, then the write may not be posted.  The 
>| >ack_complete
>| >| >will have to be generated by SW and placed on the AT response queue.
>| >| >
>| >| >For the ack_complete's that are sent for the mid-memory range,
>ordering,
>| >if 
>| >
>| >| >required is provided by SW.  This is because both reads and writes of 
>this
>| >| >space must be handled by SW. 
>| >| >
>| >| >David
>| >| >
>| >| >"Yehuda Peled" <PELED@HAIFASC3.HAIFA.IBM.COM> Wrote:
>| >| >| 
>| >| >| Comments embedded below.
>| >| >| 
>| >| >| >>Slightly revised rules:
>| >| >| >>
>| >| >| >> 1) There are no ordering relationships between asynchronous and 
>| >| >isochronous
>| >| >| >>packets.
>| >| >| >>
>| >| >| >> 2) Posted asynchronous write requests MAY pass any other 
>asynchronous
>| >| >| >>request in ANY inbound FIFO or DMA context.
>| >| >| >>
>| >| >| >> 3) Asynchronous requests in ANY inbound FIFO or DMA context SHALL 
>NOT
>| >| >pass
>| >| >| >>any posted asynchronous write request.
>| >| >| 
>| >| >| What about posted writes that are forwarded to the DMA context (not
>| >| >| a Physical DMA). How can we insure that a physical read request will
>| >| >| not pass those posted writes ?
>| >| >| The problem is that there is no way to know when the device driver 
>will
>| >| >| process those posted write.
>| >| >| 
>| >| >| >>
>| >| >| >>
>| >| >| >>Regards,
>| >| >| >>
>| >| >| >>Peter
>| >| >| >>
>| >| >| >>
>| >| >| 
>| >| >| Regards,
>| >| >|  Yehuda
>| >| >| 
>| >| 
>| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, February 19, 1997 11:14 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: More questions about IT DMA

Behavior does not assume a large FIFO.  Unless the FIFO is non-existant, the 
host side will be working ahead.  One can set the limits so that it only works 
ahead by one (start fetching now for the next cycle) but waiting for the cycle 
start to start fetching (that's the only case when the host and link side can 
use the same timer/counter) is probably a bit risky.

David

mis@aluxs.micro.lucent.com (Michael Shinkarovsky) Wrote:
| 
| DavidW@bangate.compaq.com wrote:
|  
| > Since the host side and the link side are not time synchronized, the host 
side 
| 
| > must have its own cycle timer.  This keeps track of the cycle number for 
which 
| 
| > data is being put into the FIFO.  It is _not_ the same cycle timer that 
the 
| > link side uses.  When the chip is initialized, the timers are set to the 
same 
| > value and then the host side can start putting things in the FIFO.  It has 

| > been suggested that the first thing that the host side should do is to 
place 
| > two end of cycle delimiters in the FIFO to get some time to work.  It then 

| > starts its normal processing.  When difference between host side cycle  
time 
| > and link side cycle time is less than two, the host can start putting 
things 
| > into the FIFO.
| 
| I guess David meant to say that the host side has a cycle counter (nee 
timer). I 
| read an implication that host side is going to increment this counter after 
it 
| puts a cycle delimiter into IT FIFO. Correct?
| 
| Also, is this behaviour mostly hypothetical anyway because it assumes a 
_large_ 
| sized IT FIFO to accomodate 2 cycles worth of IT packets. I agree that a 
| separate cycle_counter is probably useful, but in reality it will mostly 
have 
| the same value as link side cycle_timer.
| 
| Mike
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, February 19, 1997 11:45 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: RE: RE: RE: Re: Posted Writes and SBP-2

John,

I think I am in violent agreement with you.  Avoiding the problems of the 3 
party transaction is not terribly difficult.  However, if we disallow those 
things someone is going to raise hell at us about how we eliminated support 
for their favorite way of doing something.  Others will scoff at our lack of 
architectural purity.

But, like I said, I think this is something that needs to be addressed in a 
larger audience (I wish I knew what the right audience was.)

David

John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
| 
| David,
| 
| Well, you said it wasn't a _good_ example.  I'm not trying to say that
| such things are not possible in theory, just that I find it hard to
| imagine anyone trying to define a protocol to do something like this,
| much less an OS trying to use it.  It seems a shame for OHCI to
| sacrifice performance or become more complex just to support something
| that will probably never be used; especially when there is a software
| workaround, i.e. just make sure all nodes involved in the protocol have
| the same physical access characteristics (enabled or disabled).
| 
| jnf
| 
| >-----Original Message-----
| >From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
| >Sent:	Wednesday, February 19, 1997 10:34 AM
| >To:	1394ohci-l@austin.ibm.com
| >Subject:	re: RE: RE: Re: Posted Writes and SBP-2
| >
| >John,
| >
| >Since you asked for an example and not a _good_ example, here goes...
| >
| >Suppose we are doing a copy from one device to another.  Furthermore, 
suppose
| >that neither of these devices has a lot of local memory so they are using
| >host 
| >memory as a buffer.  Device A finishes a transfer to system memory and then 

| >tells device B that the data is now available and it can complete the copy. 
 
| >If the host posts the write and returns ack_complete to device A then 
device
| >A 
| >can inform device B that the data is available.  So, device B goes to get 
the
| >data and ...
| >
| >Now, this is, admittedly, not a good example.  It is, however, an example 
of
| >a 
| >protocol that is not otherwise precluded by serial bus.  I don't 
necessarily 
| >mind disallowing such protocols but I'm not sure that that is something we 
| >would take on in the context of OHCI (seems like something that one would 
do 
| >in the 1394A context.)
| >
| >David
| >
| >John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
| >| 
| >| David,
| >| 
| >| Can you give me an example of a protocol that involves 3 nodes?  I know
| >| of none except for isochronous which is not a problem.  Although a case
| >| is allowed for in SBP-2 to have a device transfer data into/from a node
| >| that is not the initiator (Node A being the device, Node B being the
| >| initiator, and Node C being the recipient of the data), I can't imagine
| >| this being done without Node B forwarding Node A's completion notice to
| >| Node C such that it goes through the AR DMA instead of the physical DMA.
| >| 
| >| As for finding out which devices do things they shouldn't, this won't be
| >| done on the fly in the user's environment.  But we will become aware of
| >| those devices through several channels, for example: logo qualification
| >| tests on a device could run in untested mode and verify all
| >| transactions; field reports of system failures can lead to a particular
| >| device; and certain classes of devices will simply never be trusted.
| >| 
| >| jnf
| >| 
| >| >-----Original Message-----
| >| >From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
| >| >Sent:	Tuesday, February 18, 1997 3:54 PM
| >| >To:	1394ohci-l@austin.ibm.com
| >| >Subject:	re: RE: Re: Posted Writes and SBP-2
| >| >
| >| >John,
| >| >
| >| >I think there is a hole. If node A does a write that gets posted.  Node 
A 
| >| >thinks write is done.  So, node A notifies node B to go get the results 
of
| >| >the 
| >| >write which are now available in the host.  Node B, which has access 
| >| >privileges, comes and reads the data which is stale because the posted 
| >write 
| >| >that ended up in the AR request queue, hasn't been processed by 
software.
| >| >
| >| >Question about your statement in paragraph two.  If a 1394 device with 
| >| >privileges accesses something that it isn't supposed to, how would you 
| >know?
| >| >
| >| >David
| >| >
| >| >John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
| >| >| 
| >| >| As I said in my earlier mail, I believe you can still post writes into
| >| >| the AR request context because reads from that same node will also be
| >| >| placed in the AR request context.
| >| >| 
| >| >| Please note, no device on 1394 is expected to just go out and make up
| >| >| addresses it wants to read and write in host memory.  If one does then
| >| >| you can bet that we will disable its physical access.  In general
| >| >| devices talk to addresses that they have been told to talk to and no
| >| >| where else.
| >| >| 
| >| >| >-----Original Message-----
| >| >| >From:	DavidW@bangate.compaq.com 
[SMTP:DavidW@bangate.compaq.com]
| >| >| >Sent:	Tuesday, February 18, 1997 8:56 AM
| >| >| >To:	1394ohci-l@austin.ibm.com
| >| >| >Subject:	re: Re: Posted Writes and SBP-2
| >| >| >
| >| >| >An implication of the proposed ordering rules is that, when a write
| >| >request
| >| >| >is 
| >| >| >to a physical memory address but the access filter(s) causes that 
write
| >to
| >| >go
| >| >| >to the AR request buffer, then the write may not be posted.  The 
| >| >ack_complete
| >| >| >will have to be generated by SW and placed on the AT response queue.
| >| >| >
| >| >| >For the ack_complete's that are sent for the mid-memory range,
| >ordering,
| >| >if 
| >| >
| >| >| >required is provided by SW.  This is because both reads and writes of 

| >this
| >| >| >space must be handled by SW. 
| >| >| >
| >| >| >David
| >| >| >
| >| >| >"Yehuda Peled" <PELED@HAIFASC3.HAIFA.IBM.COM> Wrote:
| >| >| >| 
| >| >| >| Comments embedded below.
| >| >| >| 
| >| >| >| >>Slightly revised rules:
| >| >| >| >>
| >| >| >| >> 1) There are no ordering relationships between asynchronous and 
| >| >| >isochronous
| >| >| >| >>packets.
| >| >| >| >>
| >| >| >| >> 2) Posted asynchronous write requests MAY pass any other 
| >asynchronous
| >| >| >| >>request in ANY inbound FIFO or DMA context.
| >| >| >| >>
| >| >| >| >> 3) Asynchronous requests in ANY inbound FIFO or DMA context 
SHALL 
| >NOT
| >| >| >pass
| >| >| >| >>any posted asynchronous write request.
| >| >| >| 
| >| >| >| What about posted writes that are forwarded to the DMA context (not
| >| >| >| a Physical DMA). How can we insure that a physical read request 
will
| >| >| >| not pass those posted writes ?
| >| >| >| The problem is that there is no way to know when the device driver 
| >will
| >| >| >| process those posted write.
| >| >| >| 
| >| >| >| >>
| >| >| >| >>
| >| >| >| >>Regards,
| >| >| >| >>
| >| >| >| >>Peter
| >| >| >| >>
| >| >| >| >>
| >| >| >| 
| >| >| >| Regards,
| >| >| >|  Yehuda
| >| >| >| 
| >| >| 
| >| 
| 
From:	rhsheu@sis.com.tw
Sent:	Wednesday, February 19, 1997 6:22 PM
To:	1394ohci-l@austin.ibm.com
Cc:	rhsheu@sis.com.tw
Subject:	GUID ROM register

Hi,

        After we write a '1' to rdStart bit in the GUID ROM register, it
will start a read of the currently addressed ROM byte. But when to clear
this bit ?
        The Access Tag of rdStart bit in GUID ROM register is "rw" instead
of "rwu". It means OHCI hardware are not allowed to update(clear) this bit.
So, software must write a '0' to this bit before it want to write a '1' to
start next read. Is that right?

Best Regard,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ruey-Horng Sheu
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4323
Fax: 886-3-5778774
Email: rhsheu@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

From:	mjlu@sis.com.tw
Sent:	Wednesday, February 19, 1997 11:49 PM
To:	1394ohci-l@austin.ibm.com
Subject:	More questions about IT DMA ( Part II )

Hi,all:

Thanks again for all of your descriptions about IT DMA, but there are still 
something not clear.

The questions are:
1.In David Wooten's answer mentions that "host side must have its own cycle 
timer to track the  cycle number for which data is being put into the FIFO" 
and "the host side cycle timer will check to match ContextControl.cycleMatch 
for precise synchronization of the start time of a context or contexts". If 
IT DMA must maintain a cycle timer, and this is not a standard 
interface(like 1394 OHCI register), how can software track the cycle number 
in ITDMA to append more packets after a while ? And since the cycle timer in 
link layer may be changed, software is hard to guess the relationship 
between link side and host side, then how can software set the 
ContextControl.cycleMatch ? 

Our expectation is the  ContextControl.cycleMatch is used to mach the link 
side cycle timer (1394 OHCI register offset 11'h0F0, Isochronous Cycle 
Timer), it  has the characteristics of
(1)"time decoupling of the input of the FIFO from the output of the FIFO" =>

 the context just reference the cycle timer in link side at the beginning of 
processing the context, after that cycle timer has nothing to do with the 
context unless the context is finished and restart again. Following input of 
the FIFO will not check the cycle timer, ITDMA will function at its own 
cycle which all of the data that is to be sent during a 1394 cycle.
(2)"The time between when data is put into the FIFO and when it is taken out 
of the FIFO can be as long as 2" =>

Since 2 cycle end delimiters are placed in the FIFO when run is set, thus if 
current cycle timer is 2000 and ContextControl.cycleMatch is 2005 for all 
contexts. In cycle 2005,data are transfered into FIFO,thus it may transmit 
to 1394 bus on cycle 2007. The IT FIFO still can work ahead of the link side 
of the FIFO.
(3)This way can provide an interface for software to track the cycle number 
which ITDMA refers, thus if the contexts stop then restart, they can keep 
synchronization easily.
(4)This way can prevent hardware to implement a counter.
Do I miss any conditions? Whether this make sense?

2.In Eric W. Anderson's answer mentions that "how DMA side and link side
coordinate the processing of a cycle loss". Doesn't the link side tell DMA 
side that cycle loss occur, then DMA side skip packet at proper time ? Is 
there anything should be handled ?

Thanks for your time and answer.






====================================================
Mei-Jiuan Lu
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
Phone:     886-35-774922 ext 4322
Fax:          886-35-790651
Email:      mjlu@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan
====================================================
From:	DavidW@bangate.compaq.com
Sent:	Thursday, February 20, 1997 8:17 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: More questions about IT DMA ( Part II )

See below.


David


mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
| 
| Hi,all:
| 
| Thanks again for all of your descriptions about IT DMA, but there are still 
| something not clear.
| 
| The questions are:
| 1.In David Wooten's answer mentions that "host side must have its own cycle 
| timer to track the  cycle number for which data is being put into the FIFO" 
| and "the host side cycle timer will check to match ContextControl.cycleMatch 

| for precise synchronization of the start time of a context or contexts". If 
| IT DMA must maintain a cycle timer, and this is not a standard 
| interface(like 1394 OHCI register), how can software track the cycle number 
| in ITDMA to append more packets after a while ? 

Appending doesn't require any knowledge of where the host side is operating.  
However, since the host side can be up to two cycles ahead of the link side, 
the software should make sure that it is queuing at least 2 cycles ahead of 
bus time.

| And since the cycle timer in 
| link layer may be changed, software is hard to guess the relationship 
| between link side and host side, then how can software set the 
| ContextControl.cycleMatch ? 

SW sets cycleMatch register for some time in the future (usually, many 
cycles.)  Because of software latencies, it is not pratical for SW to try to 
manage the startup of a channel too close to the current time.

I hope everyone remenbers that the host side is not allowed to work more than 
two cycles into the future.  If the host could work indefinately into the 
future, we _would_ have a problem.

| 
| Our expectation is the  ContextControl.cycleMatch is used to mach the link 
| side cycle timer (1394 OHCI register offset 11'h0F0, Isochronous Cycle 
| Timer), it  has the characteristics of
| (1)"time decoupling of the input of the FIFO from the output of the FIFO" =>
|  the context just reference the cycle timer in link side at the beginning of 

| processing the context, after that cycle timer has nothing to do with the 
| context unless the context is finished and restart again. Following input of 

| the FIFO will not check the cycle timer, ITDMA will function at its own 
| cycle which all of the data that is to be sent during a 1394 cycle.
| (2)"The time between when data is put into the FIFO and when it is taken out 

| of the FIFO can be as long as 2" =>

No.  The cycleMatch is compared against the value of the cycle counter/timer 
that the host side is using.  The compare is not against the link side timer.

| 
| Since 2 cycle end delimiters are placed in the FIFO when run is set, thus if 

| current cycle timer is 2000 and ContextControl.cycleMatch is 2005 for all 
| contexts. In cycle 2005,data are transfered into FIFO,thus it may transmit 
| to 1394 bus on cycle 2007. The IT FIFO still can work ahead of the link side 

| of the FIFO.
| (3)This way can provide an interface for software to track the cycle number 
| which ITDMA refers, thus if the contexts stop then restart, they can keep 
| synchronization easily.
| (4)This way can prevent hardware to implement a counter.
| Do I miss any conditions? Whether this make sense?

The host and link side are not synchronized.  The host side may start out two 
cycles ahead, but, depending on FIFO sizes and packet sizes and other things, 
it might be current (as soon as host side puts data into the FIFO, it is taken 
out by the link side and sent on the bus.)  So, the two cycle offset between 
the host side and the link side is not constant.  Solution is to have a host 
side counter that is intitialized to be the same as the link side and then is 
allowed to be offset by as much as two from the link side.

| 
| 2.In Eric W. Anderson's answer mentions that "how DMA side and link side
| coordinate the processing of a cycle loss". Doesn't the link side tell DMA 
| side that cycle loss occur, then DMA side skip packet at proper time ? Is 
| there anything should be handled ?

I don't understand what you mean by "at proper time."  When the link side 
tells the host side that a cycle was lost, the host side does skip processing 
for all active contexts.  There is no data put into the FIFO for whatever 
cycle number that the host side is currently using (cycleMatch processing does 
take place.)  After the skip processing, the host side increments the cycle 
counter/timer and starts on the next cycle's worth of data (it might also be 
skipped depending on how many cycles were lost.)

| 
| Thanks for your time and answer.
| 
| 
| ====================================================
| Mei-Jiuan Lu
| Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.
| Phone:     886-35-774922 ext 4322
| Fax:          886-35-790651
| Email:      mjlu@sis.com.tw
| Address: No 16, Creation Rd 1, 
|                  Science-based Industrial Park,
|                  Hsin Chu, Taiwan
| ====================================================
| 
| 
From:	yehiel engel [YENGEL@HAIFASC3.HAIFA.IBM.COM]
Sent:	Monday, February 24, 1997 9:58 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Physical Read Request

Hello
My name is Yehiel Engel.
I'm a design engineer in IBM Israel. I'm working (with Yehuda Peled)
on the HCI design.
I have some questions related to the physical read
error (HCI spec Draft 0.91, clause 13.2.7).

1. According to the clause if the device replies with ack_data_error
   the host should retry the packet.
   According to the 1394 spec the node should retry the packet
   transmission only if it receive a Busy ack.
   What does the initiator expect from the host control to do on
   such cases? It is important that the host behavior correlates with what
   the initiator expect.
   How this retry relates to the MaxPhysRespRetries value ?
   This behavior is different from the other async channels, and require
    additional silicon and complexity.

2. If Host controller receives a Host bus error on the first read,
   then a response packet with resp_data_error is transmitted. Why
    should we do such optimization (new mechanism for response
    packet with resp_data_error code generation) for an error?
    I think that discarding the packet is much simple.

3. How does the Host controller behave when the MaxPhysRespRetries
    value is reached? I think that the Host controller should simply
    discard this packet.

Any comment will be appreciate.

Regards
Yehiel Engel
From:	yehiel engel [YENGEL@HAIFASC3.HAIFA.IBM.COM]
Sent:	Monday, February 24, 1997 10:12 AM
To:	1394ohci-l@austin.ibm.com
Cc:	YENGEL@HAIFASC3.HAIFA.IBM.COM
Subject:	Physical Read Request

Hello
My name is Yehiel Engel.
I'm a design engineer in IBM Israel. I'm working (with Yehuda Peled)
on the HCI design.
I have some questions related to the physical read
error (HCI spec Draft 0.91, clause 13.2.7).

1. According to the clause if the device replies with ack_data_error
   the host should retry the packet.
   According to the 1394 spec the node should retry the packet
   transmission only if it receive a Busy ack.
   What does the initiator expect from the host control to do on
   such cases? It is important that the host behavior correlates with what
   the initiator expect.
   How this retry relates to the MaxPhysRespRetries value ?
   This behavior is different from the other async channels, and require
    additional silicon and complexity.

2. If Host controller receives a Host bus error on the first read,
   then a response packet with resp_data_error is transmitted. Why
    should we do such optimization (new mechanism for response
    packet with resp_data_error code generation) for an error?
    I think that discarding the packet is much simple.

3. How does the Host controller behave when the MaxPhysRespRetries
    value is reached? I think that the Host controller should simply
    discard this packet.

Any comment will be appreciate.

Regards
Yehiel Engel
From:	mjlu@sis.com.tw
Sent:	Monday, February 24, 1997 11:17 PM
To:	1394ohci-l@austin.ibm.com
Subject:	STORE_VALUE command in skipped packet

Hi,all:

I have one question about Isochronous Transmit DMA:

In OHCI v0.91,page 94, Figure 9-9, packet A4 and A5 are skipped due to bus
reset, if there is STORE_VALUE command in A4 or A5, should this STORE_VALUE
command be executed or it will also be skipped ?

Thanks for your time and answer.

From:	cylin@sis.com.tw
Sent:	Tuesday, February 25, 1997 2:04 AM
To:	1394ohci-l@austin.ibm.com
Subject:	IT STORE_VALUE data write error

Hi,

I have a question about IT STORE_VALUE data write error:
In page 122, Sec. 13.2.4, it said "The Host Controller may not begin
placing the packet associated with a STORE_VALUE into the output
FIFO until the STORE_VALUE operation is complete. This is to prevent
the possibility of having multiple errors that cannot be properly
reported to system software." My question is, since status update and
interrupt (for commmand completion) are not allowed in STORE_VALUE,
how can this data write error be reported to the system software? 

Thanks for your time and answer,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From:	Yehuda Peled (972-4-8296149) [PELED@HAIFASC3.HAIFA.IBM.COM]
Sent:	Wednesday, February 26, 1997 5:54 AM
To:	1394ohci-l@austin.ibm.com
Subject:	STORE_VALUE command

What is the purpose of this command ?
Why it is implemented only in the IT channel ?

Thanks
 Yehuda

From:	Eric W. Anderson [ewa@apple.com]
Sent:	Wednesday, February 26, 1997 11:02 AM
To:	Yehuda Peled (972-4-8296149); 1394ohci-l@austin.ibm.com
Subject:	Re: STORE_VALUE command

>What is the purpose of this command ?
>Why it is implemented only in the IT channel ?
>
>Thanks
> Yehuda

OHCI 0.91 section 9.1.1 explains that STORE_VALUE can be used for
software synchronization without interrupts.  A running IT program
can perform STORE_VALUE from time to time into a memory location
where software will look to find the latest IT progress.  If low-
latency synchronization is not required, this method is likely to
have less overhead.

In the IRDMA, software can just examine the status in the descriptor
blocks, because status is updated after every packet is received if
bufferFill mode is being used or if s=1.  In the ITDMA, setting s=1
for every packet would be wasteful - STORE_VALUE commands used in
only a few of the descriptors can conserve PCI (or other) cycles,
compared to s=1.

Setting s=1 in only some ITDMA descriptors might be problematic if
there is cycle loss and some descriptors are skipped.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------



From:	calvinn@lsi.sel.sony.com
Sent:	Wednesday, February 26, 1997 4:57 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Big/Little Endian

Hi,

I would like to bring up the subject of Big/Little Endian again. Even though
Robert Macomber helped me understand a lot more about Big/Little Endian;
however, I am still confused in how to implement it in Open HCI. To make my
questions clearer, consider the following picture:

		------------- 1394 bus
		      |
		      |	(1)
	              V
	 	+-----------+
		| 1394 Link |
	 	+-----------+
		      |
		      |	(2)
	              V
	 	+-----------+
		|   FIFO    |
	 	+-----------+
		      |
		      |	(3)
	              V
	 	+-----------+
		|   DMA     |
	 	+-----------+
		      |
		      |	(4)
	              V
	 	+-----------+
		|  PCI i/f  |
	 	+-----------+
		      |
		      |	(5)
	              V
		------------- PCI bus

Assuming @ node (1) 1394 Link receives a Block Write Request Receive Packet
as follow:

	time			byte#	Value
	 |	destID		1,2 
	 |	tLabel 		3
	 |	tCode 		4
	 |	sourceID 	5,6
	 |	destOffHi 	7,8	1111h (GRU) / 0000h (Physical DMA)
	 |	destOffLo 	9-12	0000_0201h
	 |	dataLength 	13,14	6 (bytes of data)
	 |	exTcode 	15,16
	 |	blockData 	17-24	A,B,C,D,E,F
	 |	xferStat 	25,26
	 |	timeStamp 	27,28
	 V


Here are my questions:

1. I know that the 2 bits noByteSwapData & PCI_Global_Swap each controls a
   Swapping Unit; but exactly where are those units located in the above 
   picture ? I guess the PCI_Global_Swap Unit is at node (4), but what 
   about the noByteSwapData Unit ?

2. These 2 bits create 4 combinations: 00, 01, 10, 11
   a) Assume we are dealing with GRU transfer, can anyone help me to draw
      how the packet is arranged at nodes (2), (3), (4), (5) for each
      combination ?
   b) What about Physical DMA transfer ?
From:	DavidW@bangate.compaq.com
Sent:	Thursday, February 27, 1997 10:08 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: IT STORE_VALUE data write error

Section 13.2.3 (Transmit Data Read Error) says:
"... The Host Controller will not stop processing for the context.  Instead, 
the ack code in the status of the OUTPUT_LAST_* descriptor is optionally set 
to indicate that there was an error and the nature of the error."

Section 13.2.4 (Isochronous Transmit Data Write Error) says:
"This error is handled like a data read error with the exception that the ack 
code is set to "evt_data_write".

David

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi,
| 
| I have a question about IT STORE_VALUE data write error:
| In page 122, Sec. 13.2.4, it said "The Host Controller may not begin
| placing the packet associated with a STORE_VALUE into the output
| FIFO until the STORE_VALUE operation is complete. This is to prevent
| the possibility of having multiple errors that cannot be properly
| reported to system software." My question is, since status update and
| interrupt (for commmand completion) are not allowed in STORE_VALUE,
| how can this data write error be reported to the system software? 
| 
| Thanks for your time and answer,
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	cylin@sis.com.tw
Sent:	Thursday, February 27, 1997 11:27 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: IT STORE_VALUE data write error

Hi, David:

Thanks for your answer. But I think the problem is still there.
The ack code in the status of the OUTPUT_LAST_* descriptor can be 
reported back to the system software if s=1. Or one can set i=2b'11
to issue a interrupt such that system software may look at the
ack code at the ContextControl register. However, for STORE_VALUE
descriptor, none of s, XferStatus or i fields are valid. This means
HW has no way to report this evt_data_write error to SW even if
it sets the ack code in the ContextControl register. If HW
keeps on processing the following OUTPUT_* descriptors, and a data
read error occurs, then SW will see a "evt_data_read" instead of
"evt_data_write" (through the s or i approach). There's problem in
"prevent the possibility of having multiple errors that cannot be 
properly reported to system software", as stated in the spec.!

C.Y.

>Section 13.2.3 (Transmit Data Read Error) says:
>"... The Host Controller will not stop processing for the context.  Instead, 
>the ack code in the status of the OUTPUT_LAST_* descriptor is optionally set 
>to indicate that there was an error and the nature of the error."
>
>Section 13.2.4 (Isochronous Transmit Data Write Error) says that "this error 
>is handled like a data read error with the exception that the ack code is set 
>to "evt_data_write".
>
>David
>
>cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
>| 
>| Hi,
>| 
>| I have a question about IT STORE_VALUE data write error:
>| In page 122, Sec. 13.2.4, it said "The Host Controller may not begin
>| placing the packet associated with a STORE_VALUE into the output
>| FIFO until the STORE_VALUE operation is complete. This is to prevent
>| the possibility of having multiple errors that cannot be properly
>| reported to system software." My question is, since status update and
>| interrupt (for commmand completion) are not allowed in STORE_VALUE,
>| how can this data write error be reported to the system software? 
>| 
>| Thanks for your time and answer,
>| 
>| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>| Chien-Yuh Lin
>| Design Engineer
>| Basic Technology Group
>| Silicon Intergrated Systems Corp.
>| Tel: 886-3-5774922 x 4326
>| Fax: 886-3-5778774
>| Email: cylin@sis.com.tw
>| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>| 
>| 
>
>

From:	DavidW@bangate.compaq.com
Sent:	Friday, February 28, 1997 10:39 AM
To:	1394ohci-l@austin.ibm.com
Subject:	fwd: re: AT and Bus reset.

Comments By: David Wooten@Desktop@PCPD Hou
Originally To: SMTP@PCPD Hou G1@Servers[<PELED@HAIFASC3.HAIFA.IBM.COM>]
Originally From: David Wooten@Desktop@PCPD Hou
Original Date:  2/28/97  12:38 PM
Comments:



-------------------------[Original Message]--------------------------

Yehuda,

Comments below.

David


"Yehuda Peled (972-4-8296149)" <PELED@HAIFASC3.HAIFA.IBM.COM> Wrote:
| 
| According to the HCI Draft 0.91 section 7.2.2.1 when a bus reset occurs,
| the Host Controller flushes the asynchronous transmit FIFO(s) and return an
| evt_flushed status.
| In section 3.1.3 it is stated that the Host Controller clears the
| ContextControl.active bit.
| 
| I have two comments:
| 
| 1.In section 7.2.2.1 it is not clear that the Host Controller clear the
| ContextControl.active bit and stop the AT contexts operation.

OK, but I just read over the description in 3.1.3 (referenced in table 7-11) 
and it states that "... for the asynchronous transmit contexts (request and 
response), the Host Controller will clear ContextControl.active when a bus 
reset occurs."

We do have a problem in that the description of IntEvent.busReset (section 
6.2.1.1) does not match up real well with section 7.2.2.1 which is a bit more 
accurate.

| 
| 2.The purpose of the evt_flushed status is not clear to me. A simpler
| mechanism is just to discard the packet, and not to write any status to the
| descriptor. If there is no status then the device driver will understand 
that
| the Host Controller did not sent the packet.
| 
| I believe that the evt_flushed status is a left over from Pele. Pele does 
not
| stop the DMA context operation at bus reset, but keep fetching the packets,
| and use the EnableAT bit in the packet format to re enable the packet
| transmission.
| I think that the AT context should be stopped at bus reset, so there is no
| need to the evt_flushed status.

The spec says that the context is stopped at bus reset but that's not quite 
enough.  The host side puts things in the fifo and waits for an ack code from 
the link.  If a bus reset comes along after the host side has put something in 
the fifo but before it gets the ack code from the link, the host side doesn't 
know what happend to the packet (was it sent or not?)  If it was send and a 
reset keeps the ack from being received (I don't think this possibility is 
eliminated untill all PHYs to arbitrated short reset), then the link will 
return evt_missing_ack.  If the packet was not sent, then the link side 
returns evt_flushed so the host side can 'complete' the processing for the 
packet.

It is allowed but not required that the HC write the evt_flushed to the 
xferStatus.  Software will not use the value in commandPtr.descriptorAddress 
to determine where the asynchronous transfers stopped (SW must use the 
xferStatus of completed packets to determine that.)

One other point about this bus reset processing.  When it occurs the HC should 
treat IntEvent.busReset being set roughly equivalent to having SW clear run.  
This also applies to timing when active gets cleared.  Active is not just jam 
set to 0, it is cleared when the context is 'stable' (all data transfers 
halted and status writes completed.) 

Does this help at all?

| 
| 
| Thanks
|  Yehuda
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, February 28, 1997 1:40 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Big/Little Endian

Calvin,

Ther are lots of places where one might do the byte swap.  Any place where the 
logic understands the difference between header and data can do the swap.  
However, you might prefer to put the byteswap on the host side of the FIFO's 
so that you can do the any required alignment at the same time you do the 
swap.

I'm going to go through the scenarios for the case when PCI_GLOBAL_BYTE_SWAP = 
0.  If that is not enough, right back and I'll see if I can find the time to 
explain the others.

Just as a reminder, on the PCI bus, the bits are numbered from right to left 
and so are the bytes. Byte 0 is bits 0-7, byte 1 is 8-15, byte 2 is 16-24 and 
byte 3 is 24-31.

Remember, all the explanation below assumes PCI_GLOBAL_BYTE_SWAP = 0 with data 
coming from a PCI bus.

I'm going to assume that since you were very specific about your example, you 
don' t have any problem with the output side of things.  And, by the nature of 
your question, it seems that the byte swap is only a problem with things that 
are going to the receive request and response queues.  I think I can clarify, 
at least I hope so, without drawing too many pictures.

The data portion of packets sent to the request and response queues are byte 
swapped but they are not byte aligned.  In other words, the low order two bits 
of any offset address that might be in the packet header DO NOT affect where 
the data is written into memory.  So, your bytes of data (assuming that they 
come from 1394 as ABCDEF) will go into memory as:
	
	noByteSwapData=0	noByteSwapData=1
byte	 3   2   1   0		 3   2   1   0
	'D' 'C' 'B' 'A'		'A' 'B' 'C' 'D'
 	 P   P  'F' 'E'		'E' 'F'  P   P

Note: the P bytes are pad bytes of zero that were received from 1394.

So the whole packet will be:
	
	noByteSwapData=0	noByteSwapData=1
byte	 3   2   1   0		 3   2   1   0
	 1   2   3   4		 1   2   3   4
	 5   6   7   8		 5   6   7   8
	 9  10  11  12		 9  10  11  12
	13  14  15  16		13  14  15  16
	'D' 'C' 'B' 'A'		'A' 'B' 'C' 'D'
	 P   P  'F' 'E'		'F' 'E'  P   P
	 X   X   T   T		 X   X   T   T

(X's are xferStatus bytes and T's are timeStamp bytes. I didn't use your 
numbers for the xferStatus and timeStamp fields because these bytes are not 
sent on 1394 and, therefor, don't have a sequence number like the rest of the 
data.)

If this same packet was handled by the physical unit, all the header in 
formation is stripped and the physical unit makes sure that the data shows up 
in memory in ascending byte order.  According to your example, the inital 
offset is 201 so the data would go on PCI in the following byte order:

	noByteSwapData=0	noByteSwapData=1
byte	 3   2   1   0		 3   2   1   0		PCI 
byte lane
	'C' 'B' 'A'  X		 X  'A' 'B' 'C'		(quadlet 
200)
	 X  'F' 'E' 'D'		'D' 'E' 'F'  X		(quadlet 
201)

(X's are bytes for which byte enalble is inactive.)


Got it?

David
   
calvinn@lsi.sel.sony.com (Calvin Nguyen) Wrote:
| 
| Hi,
| 
| I would like to bring up the subject of Big/Little Endian again. Even though
| Robert Macomber helped me understand a lot more about Big/Little Endian;
| however, I am still confused in how to implement it in Open HCI. To make my
| questions clearer, consider the following picture:
| 
| 		------------- 1394 bus
| 		      |
| 		      |	(1)
| 	              V
| 	 	+-----------+
| 		| 1394 Link |
| 	 	+-----------+
| 		      |
| 		      |	(2)
| 	              V
| 	 	+-----------+
| 		|   FIFO    |
| 	 	+-----------+
| 		      |
| 		      |	(3)
| 	              V
| 	 	+-----------+
| 		|   DMA     |
| 	 	+-----------+
| 		      |
| 		      |	(4)
| 	              V
| 	 	+-----------+
| 		|  PCI i/f  |
| 	 	+-----------+
| 		      |
| 		      |	(5)
| 	              V
| 		------------- PCI bus
| 
| Assuming @ node (1) 1394 Link receives a Block Write Request Receive Packet
| as follow:
| 
| 	time			byte#	Value
| 	 |	destID		1,2 
| 	 |	tLabel 		3
| 	 |	tCode 		4
| 	 |	sourceID 	5,6
| 	 |	destOffHi 	7,8	1111h (GRU) / 0000h (Physical 

| DMA)

| 	 |	destOffLo 	9-12	0000_0201h
| 	 |	dataLength 	13,14	6 (bytes of data)
| 	 |	exTcode 	15,16
| 	 |	blockData 	17-24	A,B,C,D,E,F
| 	 |	xferStat 	25,26
| 	 |	timeStamp 	27,28
| 	 V
| 
| 
| Here are my questions:
| 
| 1. I know that the 2 bits noByteSwapData & PCI_Global_Swap each controls a
|    Swapping Unit; but exactly where are those units located in the above 
|    picture ? I guess the PCI_Global_Swap Unit is at node (4), but what 
|    about the noByteSwapData Unit ?
| 
| 2. These 2 bits create 4 combinations: 00, 01, 10, 11
|    a) Assume we are dealing with GRU transfer, can anyone help me to draw
|       how the packet is arranged at nodes (2), (3), (4), (5) for each
|       combination ?
|    b) What about Physical DMA transfer ?
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, February 28, 1997 9:50 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: IT STORE_VALUE data write error

The 's' fields ad the 'i' fields of the OUTPUT_LAST* are the ones that 
determine if the status is written and/or an interrupt is generated.  The 
xferStatus field if the OUTPUT_LAST* is were a store value write error _or_ a 
data read error is conditionally (depending on 's') reported.

If an error occurs in writing the store value, the HC reads the following 
descriptors but does not transfer the data associated with the command (no iso 
data transfer takes place) so no additional data read error will occur.  If a 
descriptor read error occurs, the HC will set the 'dead' bit and report a 
descriptor read error which will take precidence over the store value or data 
read error that might have occured previously.  If there is a descriptor read 
error, then the fact that there might have been a store value error or a data 
read error is of no particular consequence (its probably bogus anyway.)

David


cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi, David:
| 
| Thanks for your answer. But I think the problem is still there.
| The ack code in the status of the OUTPUT_LAST_* descriptor can be 
| reported back to the system software if s=1. Or one can set i=2b'11
| to issue a interrupt such that system software may look at the
| ack code at the ContextControl register. However, for STORE_VALUE
| descriptor, none of s, XferStatus or i fields are valid. This means
| HW has no way to report this evt_data_write error to SW even if
| it sets the ack code in the ContextControl register. If HW
| keeps on processing the following OUTPUT_* descriptors, and a data
| read error occurs, then SW will see a "evt_data_read" instead of
| "evt_data_write" (through the s or i approach). There's problem in
| "prevent the possibility of having multiple errors that cannot be 
| properly reported to system software", as stated in the spec.!
| 
| C.Y.
| 
| >Section 13.2.3 (Transmit Data Read Error) says:
| >"... The Host Controller will not stop processing for the context.  
Instead, 
| >the ack code in the status of the OUTPUT_LAST_* descriptor is optionally 
set 
| >to indicate that there was an error and the nature of the error."
| >
| >Section 13.2.4 (Isochronous Transmit Data Write Error) says that "this 
error 
| >is handled like a data read error with the exception that the ack code is 
set 
| >to "evt_data_write".
| >
| >David
| >
| >cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| >| 
| >| Hi,
| >| 
| >| I have a question about IT STORE_VALUE data write error:
| >| In page 122, Sec. 13.2.4, it said "The Host Controller may not begin
| >| placing the packet associated with a STORE_VALUE into the output
| >| FIFO until the STORE_VALUE operation is complete. This is to prevent
| >| the possibility of having multiple errors that cannot be properly
| >| reported to system software." My question is, since status update and
| >| interrupt (for commmand completion) are not allowed in STORE_VALUE,
| >| how can this data write error be reported to the system software? 
| >| 
| >| Thanks for your time and answer,
| >| 
| >| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| >| Chien-Yuh Lin
| >| Design Engineer
| >| Basic Technology Group
| >| Silicon Intergrated Systems Corp.
| >| Tel: 886-3-5774922 x 4326
| >| Fax: 886-3-5778774
| >| Email: cylin@sis.com.tw
| >| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| >| 
| >| 
| >
| >
| 
| 
From:	Kalaine M. Wong [Kalaine.Wong@clssnis0.amd.com]
Sent:	Friday, February 28, 1997 4:38 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Big/Little Endian

David:
	I thought the whole packet should look like this at least for the
noByteSwapData = 0 part:

noByteSwapData=0        noByteSwapData=1
byte     3   2   1   0           3   2   1   0
         4   3   2   1           1   2   3   4
         8   7   6   5           5   6   7   8
        12  11  10   9           9  10  11  12
        16  15  14  13          13  14  15  16
        'D' 'C' 'B' 'A'         'A' 'B' 'C' 'D'
         P   P  'F' 'E'         'F' 'E'  P   P
         X   X   T   T           X   X   T   T

Thanks,
Kalaine

	
DavidW@bangate.compaq.com wrote:
> 
> Calvin,
> 
> Ther are lots of places where one might do the byte swap.  Any place where the
> logic understands the difference between header and data can do the swap.
> However, you might prefer to put the byteswap on the host side of the FIFO's
> so that you can do the any required alignment at the same time you do the
> swap.
> 
> I'm going to go through the scenarios for the case when PCI_GLOBAL_BYTE_SWAP =
> 0.  If that is not enough, right back and I'll see if I can find the time to
> explain the others.
> 
> Just as a reminder, on the PCI bus, the bits are numbered from right to left
> and so are the bytes. Byte 0 is bits 0-7, byte 1 is 8-15, byte 2 is 16-24 and
> byte 3 is 24-31.
> 
> Remember, all the explanation below assumes PCI_GLOBAL_BYTE_SWAP = 0 with data
> coming from a PCI bus.
> 
> I'm going to assume that since you were very specific about your example, you
> don' t have any problem with the output side of things.  And, by the nature of
> your question, it seems that the byte swap is only a problem with things that
> are going to the receive request and response queues.  I think I can clarify,
> at least I hope so, without drawing too many pictures.
> 
> The data portion of packets sent to the request and response queues are byte
> swapped but they are not byte aligned.  In other words, the low order two bits
> of any offset address that might be in the packet header DO NOT affect where
> the data is written into memory.  So, your bytes of data (assuming that they
> come from 1394 as ABCDEF) will go into memory as:
> 
>         noByteSwapData=0        noByteSwapData=1
> byte     3   2   1   0           3   2   1   0
>         'D' 'C' 'B' 'A'         'A' 'B' 'C' 'D'
>          P   P  'F' 'E'         'E' 'F'  P   P
> 
> Note: the P bytes are pad bytes of zero that were received from 1394.
> 
> So the whole packet will be:
> 
>         noByteSwapData=0        noByteSwapData=1
> byte     3   2   1   0           3   2   1   0
>          1   2   3   4           1   2   3   4
>          5   6   7   8           5   6   7   8
>          9  10  11  12           9  10  11  12
>         13  14  15  16          13  14  15  16
>         'D' 'C' 'B' 'A'         'A' 'B' 'C' 'D'
>          P   P  'F' 'E'         'F' 'E'  P   P
>          X   X   T   T           X   X   T   T
> 
> (X's are xferStatus bytes and T's are timeStamp bytes. I didn't use your
> numbers for the xferStatus and timeStamp fields because these bytes are not
> sent on 1394 and, therefor, don't have a sequence number like the rest of the
> data.)
> 
> If this same packet was handled by the physical unit, all the header in
> formation is stripped and the physical unit makes sure that the data shows up
> in memory in ascending byte order.  According to your example, the inital
> offset is 201 so the data would go on PCI in the following byte order:
> 
>         noByteSwapData=0        noByteSwapData=1
> byte     3   2   1   0           3   2   1   0          PCI
> byte lane
>         'C' 'B' 'A'  X           X  'A' 'B' 'C'         (quadlet
> 200)
>          X  'F' 'E' 'D'         'D' 'E' 'F'  X          (quadlet
> 201)
> 
> (X's are bytes for which byte enalble is inactive.)
> 
> Got it?
> 
> David
> 
> calvinn@lsi.sel.sony.com (Calvin Nguyen) Wrote:
> |
> | Hi,
> |
> | I would like to bring up the subject of Big/Little Endian again. Even though
> | Robert Macomber helped me understand a lot more about Big/Little Endian;
> | however, I am still confused in how to implement it in Open HCI. To make my
> | questions clearer, consider the following picture:
> |
> |               ------------- 1394 bus
> |                     |
> |                     | (1)
> |                     V
> |               +-----------+
> |               | 1394 Link |
> |               +-----------+
> |                     |
> |                     | (2)
> |                     V
> |               +-----------+
> |               |   FIFO    |
> |               +-----------+
> |                     |
> |                     | (3)
> |                     V
> |               +-----------+
> |               |   DMA     |
> |               +-----------+
> |                     |
> |                     | (4)
> |                     V
> |               +-----------+
> |               |  PCI i/f  |
> |               +-----------+
> |                     |
> |                     | (5)
> |                     V
> |               ------------- PCI bus
> |
> | Assuming @ node (1) 1394 Link receives a Block Write Request Receive Packet
> | as follow:
> |
> |       time                    byte#   Value
> |        |      destID          1,2
> |        |      tLabel          3
> |        |      tCode           4
> |        |      sourceID        5,6
> |        |      destOffHi       7,8     1111h (GRU) / 0000h (Physical
> 
> | DMA)
> |        |      destOffLo       9-12    0000_0201h
> |        |      dataLength      13,14   6 (bytes of data)
> |        |      exTcode         15,16
> |        |      blockData       17-24   A,B,C,D,E,F
> |        |      xferStat        25,26
> |        |      timeStamp       27,28
> |        V
> |
> |
> | Here are my questions:
> |
> | 1. I know that the 2 bits noByteSwapData & PCI_Global_Swap each controls a
> |    Swapping Unit; but exactly where are those units located in the above
> |    picture ? I guess the PCI_Global_Swap Unit is at node (4), but what
> |    about the noByteSwapData Unit ?
> |
> | 2. These 2 bits create 4 combinations: 00, 01, 10, 11
> |    a) Assume we are dealing with GRU transfer, can anyone help me to draw
> |       how the packet is arranged at nodes (2), (3), (4), (5) for each
> |       combination ?
> |    b) What about Physical DMA transfer ?
> |

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{									 }
{			    Have a nice day :-)				 }
{									 }
{	Kalaine Mak Wong			kalaine.wong@amd.com	 }
{	Advanced Micro Devices			TEL: (408) 749-4919 or	 }
{	Platform Peripheral Division		(800) 538-8450 X44919	 }
{	Senior Design Engineer			FAX: (408) 749-4753 	 }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	DavidW@bangate.compaq.com
Sent:	Saturday, March 01, 1997 3:28 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Re: Big/Little Endian

There is a mistake in my examples. I had shown the noByteSwapData=1 case as:
        noByteSwapData=1
byte     3   2   1   0
         1   2   3   4
         5   6   7   8
         9  10  11  12
        13  14  15  16
        'A' 'B' 'C' 'D'
        'F' 'E'  P   P
         X   X   T   T

The 6th quadlet should be:

	'E' 'F'  P   P


'Header' information is never 'byte swaped.  noByteStapData only applies to:
	
1394 packet type		applicable field	1394-1995 reference
quadlet write request		"quadlet_data"		Figure 6-9
cycle start			"cycle_time_data"	Figure 6-10
quadler read response		"quadlet_data"		Figure 6-11
block write request		"data field"		Figure 6-13
lock request			"arg_value"		Figure 6-14
lock request			"data_value"		Figure 6-14
block read response		"data field"		Figure 6-15
lock response			"old_value"		Figure 6-16
isochronous packet		"data field"		Figure 6-17

All other quadlets are always filled in with the first quadlet byte going in 
the left most byte of the quadlet.


David 



"Kalaine M. Wong" <Kalaine.Wong@clssnis0.amd.com> Wrote:
| 
| David:
| 	I thought the whole packet should look like this at least for the
| noByteSwapData = 0 part:
| 
| noByteSwapData=0        noByteSwapData=1
| byte     3   2   1   0           3   2   1   0
|          4   3   2   1           1   2   3   4
|          8   7   6   5           5   6   7   8
|         12  11  10   9           9  10  11  12
|         16  15  14  13          13  14  15  16
|         'D' 'C' 'B' 'A'         'A' 'B' 'C' 'D'
|          P   P  'F' 'E'         'F' 'E'  P   P
|          X   X   T   T           X   X   T   T
| 
| Thanks,
| Kalaine
| 
| 	
| DavidW@bangate.compaq.com wrote:
| > 
| > Calvin,
| > 
| > Ther are lots of places where one might do the byte swap.  Any place where 
the
| > logic understands the difference between header and data can do the swap.
| > However, you might prefer to put the byteswap on the host side of the 
FIFO's
| > so that you can do the any required alignment at the same time you do the
| > swap.
| > 
| > I'm going to go through the scenarios for the case when 
PCI_GLOBAL_BYTE_SWAP =
| > 0.  If that is not enough, right back and I'll see if I can find the time 
to
| > explain the others.
| > 
| > Just as a reminder, on the PCI bus, the bits are numbered from right to 
left
| > and so are the bytes. Byte 0 is bits 0-7, byte 1 is 8-15, byte 2 is 16-24 
and
| > byte 3 is 24-31.
| > 
| > Remember, all the explanation below assumes PCI_GLOBAL_BYTE_SWAP = 0 with 
data
| > coming from a PCI bus.
| > 
| > I'm going to assume that since you were very specific about your example, 
you
| > don' t have any problem with the output side of things.  And, by the 
nature of
| > your question, it seems that the byte swap is only a problem with things 
that
| > are going to the receive request and response queues.  I think I can 
clarify,
| > at least I hope so, without drawing too many pictures.
| > 
| > The data portion of packets sent to the request and response queues are 
byte
| > swapped but they are not byte aligned.  In other words, the low order two 
bits
| > of any offset address that might be in the packet header DO NOT affect 
where
| > the data is written into memory.  So, your bytes of data (assuming that 
they
| > come from 1394 as ABCDEF) will go into memory as:
| > 
| >         noByteSwapData=0        noByteSwapData=1
| > byte     3   2   1   0           3   2   1   0
| >         'D' 'C' 'B' 'A'         'A' 'B' 'C' 'D'
| >          P   P  'F' 'E'         'E' 'F'  P   P
| > 
| > Note: the P bytes are pad bytes of zero that were received from 1394.
| > 
| > So the whole packet will be:
| > 
| >         noByteSwapData=0        noByteSwapData=1
| > byte     3   2   1   0           3   2   1   0
| >          1   2   3   4           1   2   3   4
| >          5   6   7   8           5   6   7   8
| >          9  10  11  12           9  10  11  12
| >         13  14  15  16          13  14  15  16
| >         'D' 'C' 'B' 'A'         'A' 'B' 'C' 'D'
| >          P   P  'F' 'E'         'F' 'E'  P   P
| >          X   X   T   T           X   X   T   T
| > 
| > (X's are xferStatus bytes and T's are timeStamp bytes. I didn't use your
| > numbers for the xferStatus and timeStamp fields because these bytes are 
not
| > sent on 1394 and, therefor, don't have a sequence number like the rest of 
the
| > data.)
| > 
| > If this same packet was handled by the physical unit, all the header in
| > formation is stripped and the physical unit makes sure that the data shows 
up
| > in memory in ascending byte order.  According to your example, the inital
| > offset is 201 so the data would go on PCI in the following byte order:
| > 
| >         noByteSwapData=0        noByteSwapData=1
| > byte     3   2   1   0           3   2   1   0          PCI
| > byte lane
| >         'C' 'B' 'A'  X           X  'A' 'B' 'C'         (quadlet
| > 200)
| >          X  'F' 'E' 'D'         'D' 'E' 'F'  X          (quadlet
| > 201)
| > 
| > (X's are bytes for which byte enalble is inactive.)
| > 
| > Got it?
| > 
| > David
| > 
| > calvinn@lsi.sel.sony.com (Calvin Nguyen) Wrote:
| > |
| > | Hi,
| > |
| > | I would like to bring up the subject of Big/Little Endian again. Even 
though
| > | Robert Macomber helped me understand a lot more about Big/Little Endian;
| > | however, I am still confused in how to implement it in Open HCI. To make 
my
| > | questions clearer, consider the following picture:
| > |
| > |               ------------- 1394 bus
| > |                     |
| > |                     | (1)
| > |                     V
| > |               +-----------+
| > |               | 1394 Link |
| > |               +-----------+
| > |                     |
| > |                     | (2)
| > |                     V
| > |               +-----------+
| > |               |   FIFO    |
| > |               +-----------+
| > |                     |
| > |                     | (3)
| > |                     V
| > |               +-----------+
| > |               |   DMA     |
| > |               +-----------+
| > |                     |
| > |                     | (4)
| > |                     V
| > |               +-----------+
| > |               |  PCI i/f  |
| > |               +-----------+
| > |                     |
| > |                     | (5)
| > |                     V
| > |               ------------- PCI bus
| > |
| > | Assuming @ node (1) 1394 Link receives a Block Write Request Receive 
Packet
| > | as follow:
| > |
| > |       time                    byte#   Value
| > |        |      destID          1,2
| > |        |      tLabel          3
| > |        |      tCode           4
| > |        |      sourceID        5,6
| > |        |      destOffHi       7,8     1111h (GRU) / 0000h (Physical
| > 
| > | DMA)
| > |        |      destOffLo       9-12    0000_0201h
| > |        |      dataLength      13,14   6 (bytes of data)
| > |        |      exTcode         15,16
| > |        |      blockData       17-24   A,B,C,D,E,F
| > |        |      xferStat        25,26
| > |        |      timeStamp       27,28
| > |        V
| > |
| > |
| > | Here are my questions:
| > |
| > | 1. I know that the 2 bits noByteSwapData & PCI_Global_Swap each controls 
a
| > |    Swapping Unit; but exactly where are those units located in the above
| > |    picture ? I guess the PCI_Global_Swap Unit is at node (4), but what
| > |    about the noByteSwapData Unit ?
| > |
| > | 2. These 2 bits create 4 combinations: 00, 01, 10, 11
| > |    a) Assume we are dealing with GRU transfer, can anyone help me to 
draw
| > |       how the packet is arranged at nodes (2), (3), (4), (5) for each
| > |       combination ?
| > |    b) What about Physical DMA transfer ?
| > |
| 
| -- 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| {									 }
| {			    Have a nice day :-)				
 
| }
| {									 }
| {	Kalaine Mak Wong			kalaine.wong@amd.com	
 }
| {	Advanced Micro Devices			TEL: (408) 749-4919 
or	
|  }
| {	Platform Peripheral Division		(800) 538-8450 X44919	

|  }
| {	Senior Design Engineer			FAX: (408) 749-4753 	

|  }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
From:	DavidW@bangate.compaq.com
Sent:	Saturday, March 01, 1997 3:40 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: STORE_VALUE command in skipped packet

Sorry about the delay in getting an answer to this.  We had to caucus.

Regardless of the case, when a iso transmit context is skipped, the command is 
not executed even if it's a STORE_VALUE. On skip, no store.

David 


mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
| 
| Hi,all:
| 
| I have one question about Isochronous Transmit DMA:
| 
| In OHCI v0.91,page 94, Figure 9-9, packet A4 and A5 are skipped due to bus
| reset, if there is STORE_VALUE command in A4 or A5, should this STORE_VALUE
| command be executed or it will also be skipped ?
| 
| Thanks for your time and answer.
| 
| 
From:	Yehuda Peled (972-4-8296149) [PELED@HAIFASC3.HAIFA.IBM.COM]
Sent:	Sunday, March 02, 1997 2:24 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Physical Read Request

We have not get any response to the following note.
Any comment will be appreciate.

Thanks
 Yehuda
---------------- Refernced note -----------------------------------------
Received: from netmail1.austin.ibm.com by VNET.IBM.COM (IBM VM SMTP V2R3)
   with TCP; Mon, 24 Feb 97 11:34:35 EST
Received: from HAIFASC3.HAIFA.IBM.COM (haifasc3.haifa.ibm.com [9.148.5.1]) by
netmail1.austin.ibm.com (8.6.12/8.6.11) with SMTP id KAA34668 for
<1394ohci-l@austin.ibm.com>; Mon, 24 Feb 1997 10:15:38 -0600
Message-Id: <199702241615.KAA34668@netmail1.austin.ibm.com>
Received: from HAIFASC3 by HAIFASC3.HAIFA.IBM.COM (IBM VM SMTP V2R2)
   with BSMTP id 2780; Mon, 24 Feb 97 18:12:36 IST
Date: Mon, 24 Feb 97 18:11:54 IST
From: "yehiel engel" <YENGEL@HAIFASC3.HAIFA.IBM.COM>
To: 1394ohci-l@austin.ibm.com
cc: YENGEL@HAIFASC3.HAIFA.IBM.COM
Subject: Physical Read Request

Hello
My name is Yehiel Engel.
I'm a design engineer in IBM Israel. I'm working (with Yehuda Peled)
on the HCI design.
I have some questions related to the physical read
error (HCI spec Draft 0.91, clause 13.2.7).

1. According to the clause if the device replies with an ack_data_error
   the host should retry the packet transmission.
   According to the 1394 spec the node should retry the packet
   transmission only if it receive a Busy ack.
   What does the initiator expect from the host control to do on
   such cases? It is important that the host behavior correlates with what
   the initiator expect.
   How this retry relates to the MaxPhysRespRetries value ?
   This behavior is different from the other async channels, and require
    additional silicon and complexity.

2. If Host controller receives a Host bus error on the first read,
   then a response packet with resp_data_error is transmitted. Why
    should we do such optimization (new mechanism for response
    packet with resp_data_error code generation) for an error?
    I think that discarding the packet is much simple.

3. How does the Host controller behave when the MaxPhysRespRetries
    value is reached? I think that the Host controller should simply
    discard this packet.

Any comment will be appreciate.

Regards
Yehiel Engel
From:	John Nels Fuller
Sent:	Sunday, March 02, 1997 7:59 PM
To:	'1394ohci-l@austin.ibm.com'; 'Yehuda Peled (972-4-8296149)'
Subject:	RE: Physical Read Request

Comments below:

>----------
>From: 	Yehuda Peled (972-4-8296149)[SMTP:PELED@HAIFASC3.HAIFA.IBM.COM]
>Sent: 	Sunday, March 02, 1997 2:24 PM
>To: 	1394ohci-l@austin.ibm.com
>Subject: 	Re: Physical Read Request
>
>We have not get any response to the following note.
>Any comment will be appreciate.
>
>Thanks
> Yehuda
>---------------- Refernced note -----------------------------------------
>Received: from netmail1.austin.ibm.com by VNET.IBM.COM (IBM VM SMTP V2R3)
>   with TCP; Mon, 24 Feb 97 11:34:35 EST
>Received: from HAIFASC3.HAIFA.IBM.COM (haifasc3.haifa.ibm.com [9.148.5.1]) by
>netmail1.austin.ibm.com (8.6.12/8.6.11) with SMTP id KAA34668 for
><1394ohci-l@austin.ibm.com>; Mon, 24 Feb 1997 10:15:38 -0600
>Message-Id: <199702241615.KAA34668@netmail1.austin.ibm.com>
>Received: from HAIFASC3 by HAIFASC3.HAIFA.IBM.COM (IBM VM SMTP V2R2)
>   with BSMTP id 2780; Mon, 24 Feb 97 18:12:36 IST
>Date: Mon, 24 Feb 97 18:11:54 IST
>From: "yehiel engel" <YENGEL@HAIFASC3.HAIFA.IBM.COM>
>To: 1394ohci-l@austin.ibm.com
>cc: YENGEL@HAIFASC3.HAIFA.IBM.COM
>Subject: Physical Read Request
>
>Hello
>My name is Yehiel Engel.
>I'm a design engineer in IBM Israel. I'm working (with Yehuda Peled)
>on the HCI design.
>I have some questions related to the physical read
>error (HCI spec Draft 0.91, clause 13.2.7).
>
>1. According to the clause if the device replies with an ack_data_error
>   the host should retry the packet transmission.
>   According to the 1394 spec the node should retry the packet
>   transmission only if it receive a Busy ack.
>   What does the initiator expect from the host control to do on
>   such cases? It is important that the host behavior correlates with what
>   the initiator expect.
>   How this retry relates to the MaxPhysRespRetries value ?
>   This behavior is different from the other async channels, and require
>    additional silicon and complexity.

Normally, an upper layer handles retries for ack_data_error while the
link layer handles ack_busy retries; however, for physical requests we
are implementing all layers in hardware therefore we need the physical
response unit to resend the packet if we get an ack_data_error for the
packet.  We didn't make it clear if MaxPhysRespRetries applies to the
ack_data_errors or not. Off the top of my head I can think of reasons to
go either way so I think that we'll have to get back to you on this
point.  But to answer your question about what the initiator expects,
the initiator will treat the packet with a data error the same as if no
packet had arrived and thus is still expecting a response from the
target.

>
>2. If Host controller receives a Host bus error on the first read,
>   then a response packet with resp_data_error is transmitted. Why
>    should we do such optimization (new mechanism for response
>    packet with resp_data_error code generation) for an error?
>    I think that discarding the packet is much simple.

It is always simpler not to do error handling, but that is not a good
excuse.  The request was initiated by a device with physical access
privilege, most probably an SBP-2 device like a disk drive.  By
reporting the error to that device it can in turn include the
information in its status report to the host software which might be
able do take corrective action, such as disabling a bank of memory.  A
high reliability system must do proper error handling and if computers
are to become consumer devices they must become high reliability
systems.

>
>3. How does the Host controller behave when the MaxPhysRespRetries
>    value is reached? I think that the Host controller should simply
>    discard this packet.

Yes, that is the correct behavior.
>
>Any comment will be appreciate.
>
>Regards
>Yehiel Engel
>
From:	wjshieh@sis.com.tw
Sent:	Monday, March 03, 1997 12:30 AM
To:	1394ohci-l@austin.ibm.com
Subject:	a question about backed out

Hi, all,

  In OHCI draft 0.91, sec. 8.4.2 mentions that packets with
data-length errors, CRC errors, FIFO overrun errors or buffer
overrun errors must be backed out. But in Table 3-2, ack_type_error
is not a packet event code in receive contexts. Since ack_type_error
is not reported to the software, I think any packet which is returned
with ack_type_error will be backet out, right?

Thanks for your time and answer,
======================================
Whieh-Jen Shieh
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp. (SiS)
Phone  : 886-3-5774922 ext. 4314
Fax    : 886-3-5790651
E-mail : wjshieh@sis.com.tw
======================================

From:	David Brief [David.Brief@nsc.com]
Sent:	Monday, March 03, 1997 5:10 AM
To:	1394ohci-l@austin.ibm.com
Subject:	OHCI 0.92 draft

What is the target date for release of the next draft?
I was under the impression that it was supposed to be out already.

Thanks,
David Brief
From:	David Brief [David.Brief@nsc.com]
Sent:	Monday, March 03, 1997 6:00 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Extended TCODE Filter for b-cast async

At one point there was discussion of using the extended TCODE field
(16 bits) as an effective channel number for the
"broadcast async stream" . This seems to make sense and be relatively
simple in hardware to implement. 

Is this idea still included in the DAVIC proposal?
Has anyone suggested putting
an optional filtering function on this into  OpenHCI?
A 16-bit bit map should be more than sufficient to handle this.

-David Brief
From:	klashman@meow.East.Sun.COM
Sent:	Monday, March 03, 1997 8:08 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: OHCI 0.92 draft

.92 will be available very soon - hopefully in the next day or so.

Diana

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


----- Begin Included Message -----

Sender: brief@nsc.com
From: David Brief <David.Brief@nsc.com>

What is the target date for release of the next draft?
I was under the impression that it was supposed to be out already.

Thanks,
David Brief


----- End Included Message -----
From:	John Nels Fuller
Sent:	Monday, March 03, 1997 10:22 AM
To:	'David Brief'; '1394ohci-l@austin.ibm.com'
Subject:	RE: Extended TCODE Filter for b-cast async

I believe this method was removed from the DAVIC proposal.  There is
talk of using an isochronous packet transmitted with asynchronous
arbitration for this an using isochronous channel numbers.  The only
thing we would have to do to accommodate this proposal would be to allow
packets with Tcode==4'hA to be placed in the AT request context, the
current multi-channel isochronous receive mode could be used to receive
the packets.

We should know more about what is happening in a few weeks.

>-----Original Message-----
>From:	David Brief [SMTP:David.Brief@nsc.com]
>Sent:	Monday, March 03, 1997 6:00 AM
>To:	1394ohci-l@austin.ibm.com
>Subject:	Extended TCODE Filter for b-cast async
>
>At one point there was discussion of using the extended TCODE field
>(16 bits) as an effective channel number for the
>"broadcast async stream" . This seems to make sense and be relatively
>simple in hardware to implement. 
>
>Is this idea still included in the DAVIC proposal?
>Has anyone suggested putting
>an optional filtering function on this into  OpenHCI?
>A 16-bit bit map should be more than sufficient to handle this.
>
>-David Brief
From:	sakurai@prd.snec.nec.co.jp
Sent:	Monday, March 03, 1997 7:13 PM
To:	1394ohci-l@austin.ibm.com
Subject:	About padding


 Hello.

 I have a question about PADDING on AT and IT packet
 on 1394OHCI draft0.91.

 If the datalength mod 4 is not zero then 1394OHCI chip
 add padding data.

 Is this true?

 Thanks for your any comments.


 Toshimi Sakurai

From:	John Nels Fuller
Sent:	Monday, March 03, 1997 10:35 PM
To:	1394ohci-l@austin.ibm.com; sakurai@prd.snec.nec.co.jp
Subject:	RE: About padding

Yes, this is true.

> ----------
> From:
> sakurai@prd.snec.nec.co.jp[SMTP:sakurai@prd.snec.nec.co.jp]
> Sent: 	Monday, March 03, 1997 7:12 PM
> To: 	1394ohci-l@austin.ibm.com
> Subject: 	About padding
> 
> 
>  Hello.
> 
>  I have a question about PADDING on AT and IT packet
>  on 1394OHCI draft0.91.
> 
>  If the datalength mod 4 is not zero then 1394OHCI chip
>  add padding data.
> 
>  Is this true?
> 
>  Thanks for your any comments.
> 
> 
>  Toshimi Sakurai
> 
> 
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Tuesday, March 04, 1997 8:13 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Write Posting and Ordering

We had a few threads going a week or so ago regarding write posting 
and ordering, but I'm not sure a conclusion or consensus was reached. 
The following are a few of my observations/questions on OHCI, write 
posting, and ordering.  I apologize for the length, but hope some 
forgiveness can be found in the completeness.  My personal 
conclusion/summary comes at the end ...
  
First, my interpretation of the spec is that the OHCI 1394 address 
space is divided into a number of regions with potentially different 
posting or ordering policies.  A bit of ASCII art to delimit the 
regions of interest:  
  
  48'hFFFF_FFFF_FFFF    +-------+       +-------+
                        |       |       |   E   |      
                        |   A   |       +-------+
                        |       |                
  48'hFFFF_0000_0000    +-------+                
                        |       |
                        |       |
                        |   B   |
                        |       |
                        |       |                
  48'h0001_0000_0000    +-------+       +-------+
                        |       |       |       |      
                        |   C   |       |   D   |
                        |       |       |       |
  48'h0000_0000_0000    +-------+       +-------+
  
                         Asynch          Physical
                           DMA             DMA
  
  Note: Address region E is fragmented and represents all of the CSR 
  like stuff which is either read or written directly by the physical 
  request unit (config ROM, GUID, etc.).
  
Allow me to "invent" some terms to describe different ordering 
relationships.  When attached to a split-transaction bus, a requester 
perceives that transactions complete in the order response subactions 
are received via the bus.  The relative order of request subactions is 
of no interest since 1394 provides no guarantee that favorable 
responses return in the order requests were issued.  In this usage, an 
ack_complete issued to create a unified transaction from a write 
request is considered a response.
  
A responder "completes" a transaction when the read or write request 
is successfully executed on the shared memory-mapped resource.  This 
resource could be physically addressable host memory, or part of some 
node state that the OS maintains (CSR stuff, for example).
  
Now for the ordering types attributed to a responder:
  
  Strong Ordered (SO)
     A responder guarantees to internally complete all transactions 
     for which responses have been sent before subsequently received 
     transaction requests are internally completed.  In practice, this 
     means that read and write requests (including posted writes) can 
     not pass a previously posted write (for which a response, i.e. 
     ack_complete, has already been issued).
  
  Relaxed Ordered (RO)
     A responder guarantees that newly received transactions will 
     internally complete in an order that maintains data coherency 
     with respect to transactions for which responses were previously 
     returned.  In practice, this means that write requests 
     (including posted writes) can not pass a previously posted 
     write.  However, a read request can freely pass previously 
     posted writes if either the target addresses are disjoint or if 
     the read response is formed by snooping the payload of the 
     posted writes.
  
  Unordered (UO)
     A responder makes no guarantee that the order of internal 
     completion match the order of issued responses.  In practice, 
     both read and write requests can pass posted writes.
  
Now for some analysis.  The 0.91 spec for OHCI maintains the following 
posting policies per region:
  
     Region A: No Posting
     Region B: Posting Allowed
     Region C: Posting Allowed
     Region D: Posting Allowed (for trusted nodes) 
     Region E: Assume no posting (?)
  
As Yehuda Peled pointed out in a previous reflector comment, it is 
nearly impossible for hardware to know when a posted write to B or C 
internally completes since delivery across the host bus alone is not 
an indication of completion.  (Software processes the request some 
time later.)  However, hardware does know when posted writes complete 
to Region D.  Thus, it is reasonable to consider what happens when the 
only ordering enforced by OHCI is that requests (read or write) to any 
region can not pass previously posted writes to Region D.
  
Based on the above rules, the following ASCII table documents the 
resulting ordering of a "1st" transaction to a specific Region 
relative to a subsequent "2nd" transaction to the same or different 
Region.  Note that I assume software processes asynchronous DMA 
requests in the order received, and that two requests within the same 
address region are also processed in the relative order received.
  
   2nd |          1st
  Trans|         Trans 
    V  | A  | B  | C  | D  | E
  -----+----+----+----+----+----
    A  | SO | SO | SO | SO | SO | No posting to A, doesn't pass D
  -----+----+----+----+----+----
    B  | SO | SO | SO | SO | SO | B can't pass D
  -----+----+----+----+----+----
    C  | SO | SO | SO | SO | SO | C can't pass D
  -----+----+----+----+----+----
    D  | SO | UO | UO | SO | SO | D passes posted writes in B & C
  -----+----+----+----+----+----
    E  | SO | UO | UO | SO | SO | E passes posted writes in B & C
  
Upon close examination of the table, I would claim that the unordered 
behavior of a transaction to C followed by a transaction to D is less 
than optimal.  Since C and D are aliases of the same 1394 device 
addresses, data coherency is at risk.  (One device does a posted write 
to C, a second device reads that same address through D.  John Nels 
Fuller and David Wooten discussed a scenario where this "may" happen.) 
This property leads to the restriction that all nodes participating in 
a protocol which rely on shared memory locations must consistently 
address those locations through either Region C or Region D, not both.
  
What if we disallow write posting to C?  (After all, for best 
performance we really, really want devices to be trusted and use the 
physical DMA.)  The following table results if write posting is not 
allowed to Region C:
  
   2nd |          1st
  Trans|         Trans 
    V  | A  | B  | C  | D  | E
  -----+----+----+----+----+----
    A  | SO | SO | SO | SO | SO | A can't pass D
  -----+----+----+----+----+----
    B  | SO | SO | SO | SO | SO | B can't pass D
  -----+----+----+----+----+----
    C  | SO | SO | SO | SO | SO | C can't pass D
  -----+----+----+----+----+----
    D  | SO | UO | SO | SO | SO | D passes posted writes in B    
  -----+----+----+----+----+----
    E  | SO | UO | SO | SO | SO | E passes posted writes in B
  
  
Only two unordered cases remain.  In both, data coherency is not an 
issue as long as Regions B, D, and E continue to represent disjoint 
1394 addresses.  However, one can not implement a protocol in which a 
posted write to B has a 1394-visible side-effect on D or E.  (Consider 
a hypothetical protocol in which a write to B has the side-effect of 
enabling new physical memory locations within D.)  This restriction is 
acceptable since Region A is available for such hypothetical protocols 
(provided enough negotiable addresses are free in A).
  
As a final performance tweak, I note that we may want to encourage the 
use of concatenated read responses.  For implementations with low host 
bus latency, we can help the cause by allowing reads to "coherently" 
pass posted writes.  As such, I would propose a relaxed ordering 
within the physical request DMA as documented in the next table.  (The 
arbitration changes to P1394a may almost entirely obviate the 
performance gain of a concatenated read.  However, one case where the 
RO rules still help is if a number of writes are posted in the queue 
when a read request is received.)  I have to admit that I don't 
understand region E that well ... if reads to CSR's in E have any 
visible side-effects, than we can't allow RO within E. 
  
   2nd |          1st
  Trans|         Trans 
    V  | A  | B  | C  | D  | E
  -----+----+----+----+----+----
    A  | SO | SO | SO | SO | SO | A can't pass D
  -----+----+----+----+----+----
    B  | SO | SO | SO | SO | SO | B can't pass D
  -----+----+----+----+----+----
    C  | SO | SO | SO | SO | SO | C can't pass D
  -----+----+----+----+----+----
    D  | SO | UO | SO | RO | SO | D passes posted writes in B    
  -----+----+----+----+----+----
    E  | SO | UO | SO | RO | SO | E passes posted writes in B
  
Allowing the RO in Regions D and E does restrict us from assigning 
registers with side-effects to those regions.  This is okay by me 
since everything within D should be actual DRAM and E is limited and 
precisely defined.
  
  
Conclusion
==========
To balance implementation reality, performance, and consistency, I 
feel the following rules are adequate and sufficient to deliver the 
ordering relationships shown in the table immediately above.
  
1) Posting by Region:
  
  Region A: No Posting
  Region B: Posting Allowed
  Region C: No Posting 
  Region D: Posting Allowed (for trusted nodes) 
  Region E: No Posting
  
2) Ordering:
  
  2.1) Read and write requests within the Asynchronous Request FIFO 
  SHALL NOT pass ANY posted writes, whether posted in the Physical OR 
  Asynchronous Request FIFO's.
  
  2.2) Within the Physical Request FIFO, read requests MAY coherently 
  pass posted writes, but writes requests and posted writes SHALL NOT 
  pass other writes posted in the Physical Request FIFO.  Physical 
  read and write requests MAY pass writes posted to the Asynchronous 
  Request FIFO.
  
3) Restrictions on Use by Region:
  
  Region A: Address may have side-effects
  Region B: Writes shall not have 1394 visible side-effects 
  Region C & D: Addresses shall not have side-effects 
  Region E: Reads shall not have 1394 visible side-effects
From:	nguyenc@kaisere.com
Sent:	Tuesday, March 04, 1997 10:49 AM
To:	1394ohci-l@austin.ibm.com
Cc:	cnguyen@ricochet.net
Subject:	Mail Subscription.


Hi There,

Please include my e-mail address in your "1394ohci-l" mailing list.


Thanks
C. Nguyen

nguyenc@kaisere.com
phone: 408-432-3000 x 1733

From:	DavidW@bangate.compaq.com
Sent:	Tuesday, March 04, 1997 7:48 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Wait control for bufferFill IR

See below.

David

shuming@sis.com.tw Wrote:
| 
| Hi, David,
|  
|   I am still not sure the usage of Wait in buffer-fill mode. You 
| mention: "wait should be examined on each packet to see if it
|  needs to be applied to the incoming packet". Does it mean that every 
| packet received by using this descriptor should meet the wait 
| condition? Or just the first one match, the following packet can be 
| received?

Wait check is applied to every packet.

| 
|   Another question is if both descriptor 1 and descriptor 2 set wait 
| condition (they are chained by branchAddress), if one packet straddle 
| these two buffers (pointed by these two descriptors), shall this packet need 
to 
| match the second sync condition? If yes, shall we also need to 
| consider about its back-out condition?

Wait only checked at the beginning of the packet so if a packet strattles 
multiple descriptors, only the first wait condition is checked.
| 
|   Thank you for your time and answers.
|     
| > From:          DavidW@bangate.compaq.com
| > Date:          Tue, 18 Feb 97 10:16:03 CST
| > To:            <1394ohci-l@austin.ibm.com>
| > Subject:       re: Wait control for bufferFill IR
| 
| > I need to correct this.  I have mixed up versions of the spec.  Tag is 
only a 
| > filter and has nothing to do with the wait field.
| > 
| > Wait _can_ be used in buffer-fill mode.  Strictly speaking, the wait 
should be 
| 
| > examined on each packet to see if it needs to be applied to the incoming 
| > packet.  This is of marginal use in buffer-fill mode but does allow some 
| > initial synchronization and can be used when the size of buffers is well 
| > known.
| > 
| > Sorry for the confusion.
| > 
| > David
| > 
| ***************************************************************
| Shu-Ming Liu                                                 
| Software Engineer                                            
| Software Design Department                                   
| Silicon Integrated Systems Corp.                             
| Phone 886-35-774922 ext 4157                                 
| Fax   886-35-790651                                          
| 
mailto
shuming@sis.com.tw                                  
| ***************************************************************
| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, March 04, 1997 7:37 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: a question about backed out

For packets going to AR the link does not do checking of the fields within a 
packet header (other than length) and can't check on the validity of the 
access, there shouldn't ever be a case of a packet that is destined for the AR 
to have a packet with ack_type_error.  If, however, one shows up at the link 
side, I would not suggest that you back it out.  I'd let SW see it because it 
a sign of a sick controller.

David

wjshieh@sis.com.tw (Shieh Whieh-Jen) Wrote:
| 
| Hi, all,
| 
|   In OHCI draft 0.91, sec. 8.4.2 mentions that packets with
| data-length errors, CRC errors, FIFO overrun errors or buffer
| overrun errors must be backed out. But in Table 3-2, ack_type_error
| is not a packet event code in receive contexts. Since ack_type_error
| is not reported to the software, I think any packet which is returned
| with ack_type_error will be backet out, right?
| 
| Thanks for your time and answer,
| ======================================
| Whieh-Jen Shieh
| Design Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp. (SiS)
| Phone  : 886-3-5774922 ext. 4314
| Fax    : 886-3-5790651
| E-mail : wjshieh@sis.com.tw
| ======================================
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, March 04, 1997 7:11 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Re: Re: AT and bus reset

Yehuda,

Yes.  Back the packet out.

David


"Yehuda Peled (972-4-8296149)" <ypeled@VNET.IBM.COM> Wrote:
| 
| David,
| Thanks for your response.
| I agree with your analysis.
| In our implementation, the HC will not write any status if the packet
| was not sent.
| By the way, in the AR side, if there is a bus reset after the packet
| end and before we send an acknowledge, then the packet should be backed
| out ?
| 
| Thanks
|  Yehuda
| 
| -------------------------[Original Message]--------------------------
| 
| Yehuda,
| 
| Comments below.
| 
| David
| 
| 
| "Yehuda Peled (972-4-8296149)" <PELED@HAIFASC3.HAIFA.IBM.COM> Wrote:
| |
| | According to the HCI Draft 0.91 section 7.2.2.1 when a bus reset occurs,
| | the Host Controller flushes the asynchronous transmit FIFO(s) and return 
an
| | evt_flushed status.
| | In section 3.1.3 it is stated that the Host Controller clears the
| | ContextControl.active bit.
| |
| | I have two comments:
| |
| | 1.In section 7.2.2.1 it is not clear that the Host Controller clear the
| | ContextControl.active bit and stop the AT contexts operation.
| 
| OK, but I just read over the description in 3.1.3 (referenced in table 7-11)
| and it states that "... for the asynchronous transmit contexts (request and
| response), the Host Controller will clear ContextControl.active when a bus
| reset occurs."
| 
| We do have a problem in that the description of IntEvent.busReset (section
| 6.2.1.1) does not match up real well with section 7.2.2.1 which is a bit 
more
| accurate.
| 
| |
| | 2.The purpose of the evt_flushed status is not clear to me. A simpler
| | mechanism is just to discard the packet, and not to write any status to 
the
| | descriptor. If there is no status then the device driver will understand
| that
| | the Host Controller did not sent the packet.
| |
| | I believe that the evt_flushed status is a left over from Pele. Pele does
| not
| | stop the DMA context operation at bus reset, but keep fetching the 
packets,
| | and use the EnableAT bit in the packet format to re enable the packet
| | transmission.
| | I think that the AT context should be stopped at bus reset, so there is no
| | need to the evt_flushed status.
| 
| The spec says that the context is stopped at bus reset but that's not quite
| enough.  The host side puts things in the fifo and waits for an ack code 
from
| the link.  If a bus reset comes along after the host side has put something 
in
| the fifo but before it gets the ack code from the link, the host side 
doesn't
| know what happend to the packet (was it sent or not?)  If it was send and a
| reset keeps the ack from being received (I don't think this possibility is
| eliminated untill all PHYs to arbitrated short reset), then the link will
| return evt_missing_ack.  If the packet was not sent, then the link side
| returns evt_flushed so the host side can 'complete' the processing for the
| packet.
| 
| It is allowed but not required that the HC write the evt_flushed to the
| xferStatus.  Software will not use the value in commandPtr.descriptorAddress
| to determine where the asynchronous transfers stopped (SW must use the
| xferStatus of completed packets to determine that.)
| 
| One other point about this bus reset processing.  When it occurs the HC 
should
| treat IntEvent.busReset being set roughly equivalent to having SW clear run.
| This also applies to timing when active gets cleared.  Active is not just 
jam
| set to 0, it is cleared when the context is 'stable' (all data transfers
| halted and status writes completed.)
| 
| Does this help at all?
| 
| |
| |
| | Thanks
| |  Yehuda
| |
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, March 05, 1997 7:36 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: another Big/Little Endian problem

Joe,

Answers embedded below.

David

PS view with fixed and not proportional font.

joechen@sis.com.tw (joechen) Wrote:
| 
| David:
| 
|         In your reply to Big/Little Endian problem, you have mentioned if
| the data bytes come from 1394 as ABCDEF, then the bytes of data will go into
| memory as:
| 
| noByteSwapData=0      	noByteSwapData=1
| byte    3   2   1   0 	byte     3    2   1   0
|         D   C   B   A  	         A    B   C   D
|         P   P   F   E  	         E    F   P   P
| 
| where P bytes are padding data          
| 
|         I have another question if the same condition is applied to IR and
| let buffer_fill_mode is set and isoch_header is clear. In this case,
| padding will be stripped and data bytes from various packets will be written
| into memory continuously. 
| Assume second packet comes from 1394 as follows:
| 
|         1      2     3     4
|         5      6     7     8
|         9     10    11    12
|        13     14    15    16
|         a      b     c     d
|         e      f     p      p
|         where, first 4 quadlet (from '1' to '16') denoted header.

Iso packet has single quadlet header followed by qualdet of CRC (not in fifo) 
followed by the data packet.

| 
| then, the data bytes will be written into memory as
| (a)
| NoByteSwapData=0        	noByteSwapData=1
|  byte    3   2   1   0	 byte     3    2   1   0
|          D   C   B   A   	          A    B   C   D
|          b   a   F   E	          E    F   a   b
|          f   e   d   c                  c    d   e   f
| or
| (b)
| NoByteSwapData=0       	noByteSwapData=1
|  byte    3   2   1   0 	 byte     3    2   1   0
|          D   C   B   A	          A    B   C   D
|          b   a   F   E	          a    b   E   F
|          f   e   d   c                  c    d   e   f
| which one is right ?

I think that it is fairly obvious that 'a' is correct.

The rule is that DATA bytes are sent to/from memory in ascending byte address 
order.  Becausee is defined to work on bi and little endian machines, it must 
be told how bytes are numbered within a quadler.  noByteSwapData=0 tells OHCI 
to use little endian address order for bytes within a quadlet and 
noByteSwapData=1 tells OHCI to use big endian address order for bytes within a 
quadlet.  The byte numbers in the example are the byte numbers as they appear 
on the PCI bus which is a little endian bus.
| 
|         The second problem is  I wonder whether same behavior can apply to
| transmit case. That is to say, if I want to transmit data bytes of ABCDEF to
| 1394 bus, then the bytes of data stored in memory should be
| 
| (a)
| NoByteSwapData=0       	noByteSwapData=1
|  byte    3   2   1   0	 byte     3    2   1   0
|          D   C   B   A	          A    B   C   D
|          X   X   F   E	          E    F   X   X
| (b)
| NoByteSwapData=0       	noByteSwapData=1
|  byte    3   2   1   0         byte     3    2   1   0
|          D   C   B   A                  A    B   C   D
|          X   X   F   E                  X    X   E   F
| 
| which one is right ?

If noByteSwapData=1 then we probably have a big endian machine in which case 
the address order of bytes in memory is big endian not little endian like you 
have shown above.  More apropriately, we should look at what the data looks 
like in memory and then figure out how to set noByteSwapData.

For a big endian machine the data in memory will look like:

byte     0  1  2  3  (memory byte numbering)
         A  B  C  D
         E  F  X  X

On some machines with PCI they connect the bus so that quadlets are preserved 
so if these bytesw were sent on PCI in order they would go over PCI as:

byte     3  2  1  0  (PCI byte numbering)
         A  B  C  D
         E  F  X  X

Since we want to send this data on 1394 as ABCDEF, we have to tell OHCI that 
bytes are numbered left to right (big endian order) so we set noByteSwapData=1 
and OHCI will number the bytes like:

byte     0  1  2  3  (OHCI data byte numbering when noByteSwapData=1)
         A  B  C  D
         E  F  X  X

Since we always send data bytes in ascending byte order it is sent as ABCDEF.

Note, OHCI _always_ uses big endian byte numbering (shown above) for header 
information.


For a little endian machine, the memory data is going to look like:

byte     3  2  1  0  (memory byte numbering)
         D  C  B  A
         X  X  F  E

This data is sent over PCI as:

byte     3  2  1  0  (PCI byte numbering)
         D  C  B  A
         X  X  F  E

Since we want to send this data on 1394 as ABCDEF, we have to tell OHCI that 
bytes are numbered right to left (little endian order) so we set 
noByteSwapData=0 and OHCI will number the bytes like:

byte     3  2  1  0  (OHCI data byte numbering when noByteSwapData=0)
         D  C  B  A
         X  X  F  E

and send the data in ascending byte order of ABCDEF.


| 
| Thanks for your time and answer.
| 
| Joe
| 
| PS. Your original mail about this problem is as follows :
| 
| > DavidW@bangate.compaq.com wrote:
| >
| > Calvin,
| > 
| > Ther are lots of places where one might do the byte swap.  Any place where 
the
| > logic understands the difference between header and data can do the swap.
| > However, you might prefer to put the byteswap on the host side of the 
FIFO's
| > so that you can do the any required alignment at the same time you do the
| > swap.
| > 
| > I'm going to go through the scenarios for the case when 
PCI_GLOBAL_BYTE_SWAP =
| > 0.  If that is not enough, right back and I'll see if I can find the time 
to
| > explain the others.
| > 
| > Just as a reminder, on the PCI bus, the bits are numbered from right to 
left
| > and so are the bytes. Byte 0 is bits 0-7, byte 1 is 8-15, byte 2 is 16-24 
and
| > byte 3 is 24-31.
| > 
| > Remember, all the explanation below assumes PCI_GLOBAL_BYTE_SWAP = 0 with 
data
| > coming from a PCI bus.
| > 
| > I'm going to assume that since you were very specific about your example, 
you
| > don' t have any problem with the output side of things.  And, by the 
nature of
| > your question, it seems that the byte swap is only a problem with things 
that
| > are going to the receive request and response queues.  I think I can 
clarify,
| > at least I hope so, without drawing too many pictures.
| > 
| > The data portion of packets sent to the request and response queues are 
byte
| > swapped but they are not byte aligned.  In other words, the low order two 
bits
| > of any offset address that might be in the packet header DO NOT affect 
where
| > the data is written into memory.  So, your bytes of data (assuming that 
they
| > come from 1394 as ABCDEF) will go into memory as:
| > 
| >         noByteSwapData=0        noByteSwapData=1
| > byte     3   2   1   0           3   2   1   0
| >         'D' 'C' 'B' 'A'         'A' 'B' 'C' 'D'
| >          P   P  'F' 'E'         'E' 'F'  P   P
| > 
| > Note: the P bytes are pad bytes of zero that were received from 1394.
| > 
| > So the whole packet will be:
| > 
| >         noByteSwapData=0        noByteSwapData=1
| > byte     3   2   1   0           3   2   1   0
| >          1   2   3   4           1   2   3   4
| >          5   6   7   8           5   6   7   8
| >          9  10  11  12           9  10  11  12
| >         13  14  15  16          13  14  15  16
| >         'D' 'C' 'B' 'A'         'A' 'B' 'C' 'D'
| >          P   P  'F' 'E'         'F' 'E'  P   P
| >          X   X   T   T           X   X   T   T
| > 
| > (X's are xferStatus bytes and T's are timeStamp bytes. I didn't use your
| > numbers for the xferStatus and timeStamp fields because these bytes are 
not
| > sent on 1394 and, therefor, don't have a sequence number like the rest of 
the
| > data.)
| > 
| > If this same packet was handled by the physical unit, all the header in
| > formation is stripped and the physical unit makes sure that the data shows 
up
| > in memory in ascending byte order.  According to your example, the inital
| > offset is 201 so the data would go on PCI in the following byte order:
| > 
| >         noByteSwapData=0        noByteSwapData=1
| > byte     3   2   1   0           3   2   1   0          PCI
| > byte lane
| >         'C' 'B' 'A'  X           X  'A' 'B' 'C'         (quadlet
| > 200)
| >          X  'F' 'E' 'D'         'D' 'E' 'F'  X          (quadlet
| > 201)
| > 
| 
| -------------------------------------------------------------
| Joe Chen
| Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.
| Phone:     886-3-5774922 ext 4128
| Fax:          886-3-5790651
| Email:     joechen@sis.com.tw
| Address:  No 16, Creation Rd 1, 
|                  Science-based Industrial Park,
|                  Hsin Chu, Taiwan, R. O. C.
| ------------------------------------------------------------
| 
| 
From:	PJohansson@aol.com
Sent:	Wednesday, March 05, 1997 9:48 AM
To:	P1394@sun.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	"Strict" isochronous

Contemporary 1394 link implementations, for example those based upon Apple
Computer's design, commonly permit packets with a transaction code of 0x0A
(isochronous data) to be received inside or outside of the boundaries of an
isochronous cycle. An isochronous cycle starts when a node transmits or
observes a cycle start packet and ends with the next subaction gap.

When a link operates in what is sometimes called "strict" isochronous mode,
packets with a tcode of 0x0A received outside of an isochronous cycle are
discarded.

When a link operates with this constraint removed, tcode 0x0A packets are
accepted at all times and are passed to higher layers. It is worth noting
that the current OpenHCI definition specifies ONLY this relaxed mode of
operation.

The difficulty arises in that IEEE Std 1394-1995 prohibits the "loose"
isochronous mode. Consult clause 6.3.3 and the text associated with the state
diagram. To cite just one example, look at transition L4:L0b---in which
packets that bear an isochronous tcode shall be discarded if received outside
of the asynchronous cycle.

I suggest that this is an area that should be changed in P1394a. There are
good grounds to argue that isochronous applications function with less
disruption if their isochronous packets are received EVEN if the expected
cycle start packet was not observed. Modifying P1394a to permit "loose"
isochronous operations should enhance the usability of the bus.

Regards,

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com
From:	mjlu@sis.com.tw
Sent:	Wednesday, March 05, 1997 11:40 PM
To:	1394ohci-l@austin.ibm.com
Subject:	A question about interrupt event setting due to active clear and run clear

Hi,all:

I have a question about the interrupt event setting due to active clear and 
run is already clear.

In OHCI v0.91,page 16, the 2nd paragraph in section 3.1.3.It 
describes that "When ContextControl.active is cleared and ContextControl.run 
is already clear,the  Host Controller will set the IntEvent bit for the 
context". Is this a always behavior ? Does it need to check the "i" field in 
the command which is in execution?

Thanks for your time and answer.

From:	DavidW@bangate.compaq.com
Sent:	Thursday, March 06, 1997 8:00 AM
To:	1394ohci-l@austin.ibm.com
Subject:	fwd: re: A question about interrupt event setting due to active

Comments By: David Wooten@Desktop@PCPD Hou
Originally To: SMTP@PCPD Hou G1@Servers[<mjlu@sis.com.tw>]
Originally From: David Wooten@Desktop@PCPD Hou
Original Date:  3/6/97  9:59 AM
Comments:



-------------------------[Original Message]--------------------------

This is always the behavior.  This is used as a handshake to the SW.  When SW 
commands the context to stop (clears run) the context does not stop 
immediately.  The amount of time that it takes for a context to stop can be 
significant.  So, rather than have SW wait around for active to get cleared, 
we have the HC set the interrupt when active is cleared and the context is 
stopped.

David


mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
| 
| UNDEFINED 'A question about interrupt event setting due to active clear and 
run 
| clear'
| 
| UNDEFINED
| 
| Hi,all:
| 
| I have a question about the interrupt event setting due to active clear and 
| run is already clear.
| 
| In OHCI v0.91,page 16, the 2nd paragraph in section 3.1.3.It 
| describes that "When ContextControl.active is cleared and ContextControl.run 

| is already clear,the  Host Controller will set the IntEvent bit for the 
| context". Is this a always behavior ? Does it need to check the "i" field in 

| the command which is in execution?
| 
| Thanks for your time and answer.
| 
| 
From:	mjlu@sis.com.tw
Sent:	Friday, March 07, 1997 6:41 AM
To:	1394ohci-l@austin.ibm.com
Subject:	More questions about IT DMA (part III)

Hi,all:

I have some questions about IT DMA again.

From the previous discussion about IT DMA, we got the suggestion of host 
side should maintain a cycle timer which may have 2 cycle difference from 
the link side cycle timer. My questions are:

1.How can host side keep track of the link side cycle timer?
For example:after initial, host side and link side cycle timer are zero. If 
software modify the cycle count in the link side or the link side receive a 
cycle start of cycle count =2000. What value should the host side cycle 
timer be? Does it set to 2000,or keep its own value?

2.During processing, if the link side cycle count is 2000 and host side 
cycle count is 2002. And now the link side receives a cycle start which 
tells the cycle count is 1999, how should host side handle this case?

3.During processing,there may be a new 1394 node which also a cycle master 
attached. So the cycle master may change, thus the cycle count may be 
totally different from the previous cycle count. How should host side handle 
this?

Thanks for your time and answers.

From:	klashman@meow.East.Sun.COM
Sent:	Friday, March 07, 1997 12:41 PM
To:	1394ohci-l@austin.ibm.com
Subject:	OHCI 0.92 available

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 25


OpenHCI 0.92 is now available at
ftp://www.austin.ibm.com/pub/chrptech/1394ohci/ohci092.pdf.

Attached is the checklist of changes.  The more relevant ones anyway.
(Note that the "Packet Event Codes" have been renumbered.)

Changes that have NOT been made yet include:

	- Ordering rules regarding posted writes.  The spec currently
	  describes posted writes that can go into the AR DMA Request context.

	- Clarification of LPS issues.

	- PCI powermanagement changes

	- max_rec per PJohansson email from 2/16/97

There are some others, but I think these are all the major ones.

If your favorite change has not gone in yet, please let me know and
I'll make sure it gets on the list for .93.

Diana

----------
X-Sun-Data-Type: PortableDocumentFormat-file
X-Sun-Data-Description: PortableDocumentFormat-file
X-Sun-Data-Name: revision.pdf
X-Sun-Encoding-Info: uuencode
X-Sun-Content-Lines: 299
X-Sun-Content-Length: 18337

From:	mjlu@sis.com.tw
Sent:	Monday, March 10, 1997 3:38 AM
To:	1394ohci-l@austin.ibm.com
Subject:	More question about IT DMA (part IV)

Hi,all:

In OHCI v0.92,page 95,Table9-7, and OHCI v0.91,page90,Table9-7, the 
description about cycleMatchEnable, it states that "when set to 1,the 
context will begin running only when the 13-bit cycleMatch field matches the 
13-bit cycleCount in the cycleStart packet". But in the previous discussion 
about IT DMA, Eric W.Anderson and David Wooten suggest that cycleMatch 
should match with the host side cycle timer which may have 2 cycle 
difference from the link side cycle timer. So which cycle timer should be used 
to do cycleMatch?

Thanks for your time and answer.
From:	Eric W. Anderson [ewa@apple.com]
Sent:	Monday, March 10, 1997 9:12 AM
To:	Mei-Jiuan Lu; 1394ohci-l@austin.ibm.com
Subject:	Re: More question about IT DMA (part IV)

>Hi,all:
>
>In OHCI v0.92,page 95,Table9-7, and OHCI v0.91,page90,Table9-7, the 
>description about cycleMatchEnable, it states that "when set to 1,the 
>context will begin running only when the 13-bit cycleMatch field matches
the 
>13-bit cycleCount in the cycleStart packet". But in the previous
discussion 
>about IT DMA, Eric W.Anderson and David Wooten suggest that cycleMatch 
>should match with the host side cycle timer which may have 2 cycle 
>difference from the link side cycle timer. So which cycle timer should be
>used 
>to do cycleMatch?
>
>Thanks for your time and answer.

If the cycleMatch field is programmed with value N, and the first
descriptor block in the DMA program describes a packet (this is normal),
then the DMA should start running at the time that will cause the first
packet to be transmitted on cycle N.  ie, the packet will be transmitted
after cycle start N has been sent or received, and before cycle start
N+1 is sent or received.

Because the DMA is allowed to work ahead, the channel might actually
start loading the packet into the FIFO during "real time" cycle N-1
or even N-2, so that it will be ready to go when cycle N begins.

It is possible (though uncommon) that the first descriptor in an ITDMA
program might not describe a packet.  It could, for example, have only
an OUTPUT_LAST with reqCount zero.  In that case, there is nothing to
load into the FIFO, but the context should still "begin" at the correct
time.  


--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------



From:	sakurai@prd.snec.nec.co.jp
Sent:	Monday, March 10, 1997 6:27 PM
To:	1394ohci-l@austin.ibm.com
Subject:	tCODE=4'hC


 Hello.

 1394OHCI draft0.91 wrote "tCODE=4'hA or tCODE=4'hC"
 on Figure9-10 in page95. 

 IEEE1394-1995 didn't define tCODE=4'hC.

 What does "tCODE=4'hC" means?


 Thanks for your any comments.


 Toshimi Sakurai

From:	John Nels Fuller
Sent:	Tuesday, March 11, 1997 11:54 AM
To:	'sakurai@prd.snec.nec.co.jp'; 1394ohci-l@austin.ibm.com
Subject:	RE: tCODE=4'hC

tCode=4'hC is proposed for P1394a.  It would be used to denote an
isochronous stream that contains copyrighted material (blame the
lawyers!).  It is likely, but not certain, that this will be included in
P1394a.

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> -----Original Message-----
> From:	sakurai@prd.snec.nec.co.jp [SMTP:sakurai@prd.snec.nec.co.jp]
> Sent:	Monday, March 10, 1997 6:27 PM
> To:	1394ohci-l@austin.ibm.com
> Subject:	tCODE=4'hC
> 
> 
>  Hello.
> 
>  1394OHCI draft0.91 wrote "tCODE=4'hA or tCODE=4'hC"
>  on Figure9-10 in page95. 
> 
>  IEEE1394-1995 didn't define tCODE=4'hC.
> 
>  What does "tCODE=4'hC" means?
> 
> 
>  Thanks for your any comments.
> 
> 
>  Toshimi Sakurai
> 
From:	cylin@sis.com.tw
Sent:	Tuesday, March 11, 1997 7:00 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: A question about interrupt event setting due to active clea

Hi,

DavidW@bangate.compaq.com wrote:
>This is always the behavior.  This is used as a handshake to the SW.  When SW 
>commands the context to stop (clears run) the context does not stop 
>immediately.  The amount of time that it takes for a context to stop can be 
>significant.  So, rather than have SW wait around for active to get cleared, 
>we have the HC set the interrupt when active is cleared and the context is 
>stopped.
>

If active is cleared for some other reasons before run is cleared, 
does SW expect this interrupt when run is cleared?

C.Y.

>mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
>| 
>| UNDEFINED 'A question about interrupt event setting due to active clear and 
>run 
>| clear'
>| 
>| UNDEFINED
>| 
>| Hi,all:
>| 
>| I have a question about the interrupt event setting due to active clear and 
>| run is already clear.
>| 
>| In OHCI v0.91,page 16, the 2nd paragraph in section 3.1.3.It 
>| describes that "When ContextControl.active is cleared and ContextControl.run 
>
>| is already clear,the  Host Controller will set the IntEvent bit for the 
>| context". Is this a always behavior ? Does it need to check the "i" field in 
>
>| the command which is in execution?
>| 
>| Thanks for your time and answer.
>| 
>| 
>
>
>
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	jyshiuan@sis.com.tw
Sent:	Tuesday, March 11, 1997 11:27 PM
To:	1394ohci-l@austin.ibm.com
Subject:	different speed for isochronous channel

Hi all:

  I have a question about the isochronous channel transmition.
  If I have 2 isochronous channels ready to transmition.
  The speed for channel A is 100, and channel B is 200.

  How do the OHCI to request the PHY?
  Does it request using spd 100, and then concatenate these two packets?
  or request two times using different speed?

  Thanks for your time and answer,

===============================================
Jing-Yeh Shiuan
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
E-mail:     jyshiuan@sis.comp.tw
Phone:     886-3-5774922 ext 4302
Fax:          886-3-5790651
Email:      jyshiuan@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan, R. O. C.
==============================================
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, March 12, 1997 1:43 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Write Posting and Ordering

Jerry,

Good analysis.  Just had a couple of questions which I embedded in the snippet 
below.

David

Jerry Hauck <Jerry_Hauck@ccm.sc.intel.com> Wrote:
| 
--- lots of good stuff was here ----
|   
| Conclusion
| ==========
| To balance implementation reality, performance, and consistency, I 
| feel the following rules are adequate and sufficient to deliver the 
| ordering relationships shown in the table immediately above.
|   
| 1) Posting by Region:
|   
|   Region A: No Posting
|   Region B: Posting Allowed
|   Region C: No Posting 
|   Region D: Posting Allowed (for trusted nodes) 
|   Region E: No Posting
|   
| 2) Ordering:
|   
|   2.1) Read and write requests within the Asynchronous Request FIFO 
|   SHALL NOT pass ANY posted writes, whether posted in the Physical OR 
|   Asynchronous Request FIFO's.

Just to make sure I'm clear on this.  Are you saying that if I have a posted 
write for D then I can't update the status of the AR request or response 
buffers to indicate the arrival of a packet that occured after D until D is 
written to memeory? (my question isn't all that clear either is it.)

|   
|   2.2) Within the Physical Request FIFO, read requests MAY coherently 
|   pass posted writes, but writes requests and posted writes SHALL NOT 
|   pass other writes posted in the Physical Request FIFO.  Physical 
|   read and write requests MAY pass writes posted to the Asynchronous 
|   Request FIFO.
|   
| 3) Restrictions on Use by Region:
|   
|   Region A: Address may have side-effects
|   Region B: Writes shall not have 1394 visible side-effects 

I think this is a tough one. The write has an effect.  That effect will, in 
many cases, have another effect that will visible on 1394 (i.e., a 
"side-effect".) I think the intent is to preserve causality but I don't know 
of a good way to state it.  

|   Region C & D: Addresses shall not have side-effects 
|   Region E: Reads shall not have 1394 visible side-effects
| 
From:	daisy@sis.com.tw
Sent:	Wednesday, March 12, 1997 11:10 PM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Cc:	shchuang@sis.com.tw; daisy@sis.com.tw
Subject:	question about timeStamp

Hi, all,

I notice that there are two definitions for timeStamp in OHCI v0.92,

one is
1. The low order 3 bits of cycleTimer.cycleSeconds and the full 13 bits of
   cycleTimer.cycleCount at some time during receipt (or create) this packet.
   In Table 8-3, Table 8-4, and Table 11-3

another is
2. The 3 low order bits cycleSeconds, and the full 13-bits of cycleCount
   at the most recently received(or sent) cycle start packet.
   In Table 8-5, Table 10-5

Since under some conditions, the values of these two definitions will be
different, 
[for example, the local cycleTimer has counted for 3072 in
cycleOffset, and add '1' to cycleCount, but the cycle start packet has
not come yet, then the value of the cycleCount of these two definitions
will have '1' different]
is there any reason that OHCI have to define these two difinitions of
timeStamp ?

I appreciate if anyone can clearify this, thanks.

Y.J. Chao  
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================
From:	Lakshminarayanan S [lnarayan@utopia.hclt.com]
Sent:	Thursday, March 13, 1997 5:10 AM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

From:	John Nels Fuller
Sent:	Thursday, March 13, 1997 10:53 AM
To:	'daisy@sis.com.tw'; 1394ohci-l@austin.ibm.com
Cc:	shchuang@sis.com.tw
Subject:	RE: question about timeStamp

Table 10-5 reflects the need for the IR context to precisely identify to
which isochronous cycle the packet belongs.  An isochronous packet may
come in after cycle sync but belong to the previous isochronous period
(before the new cycle start packet).  After the new cycle start packet
another packet for the same context can arrive (before the next cycle
sync).  If this packet is misidentified as belonging to the subsequent
period then software will assume there is a missing packet and attempt a
recovery procedure that may be inappropriate.  Additionally the
duplicate timestamps may confuse software.

The other places that describe timestamp (including table 8-5) are not
as sensitive to accuracy of the timestamp and should work equally well
with either definition.  The timestamp for the bus reset packet (table
8-4) is especially forgiving and merely needs to be a value between the
isochronous cycle time that the bus reset began (ala table 10-5) and the
current time when the packet is written to host memory.
_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> -----Original Message-----
> From:	daisy@sis.com.tw [SMTP:daisy@sis.com.tw]
> Sent:	Wednesday, March 12, 1997 11:10 PM
> To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
> Cc:	shchuang@sis.com.tw; daisy@sis.com.tw
> Subject:	question about timeStamp
> 
> Hi, all,
> 
> I notice that there are two definitions for timeStamp in OHCI v0.92,
> 
> one is
> 1. The low order 3 bits of cycleTimer.cycleSeconds and the full 13
> bits of
>    cycleTimer.cycleCount at some time during receipt (or create) this
> packet.
>    In Table 8-3, Table 8-4, and Table 11-3
> 
> another is
> 2. The 3 low order bits cycleSeconds, and the full 13-bits of
> cycleCount
>    at the most recently received(or sent) cycle start packet.
>    In Table 8-5, Table 10-5
> 
> Since under some conditions, the values of these two definitions will
> be
> different, 
> [for example, the local cycleTimer has counted for 3072 in
> cycleOffset, and add '1' to cycleCount, but the cycle start packet has
> not come yet, then the value of the cycleCount of these two
> definitions
> will have '1' different]
> is there any reason that OHCI have to define these two difinitions of
> timeStamp ?
> 
> I appreciate if anyone can clearify this, thanks.
> 
> Y.J. Chao  
> ====================================
> Yen-Jiuan Chao (Daisy)
> Design Engineer
> Basic Technology Group
> Silicon Integrated Systems Corp.(SiS)
> Phone  : 886-3-5774922 ext. 4315
> Fax    : 886-3-5790651
> E-mail : daisy@sis.com.tw
> =====================================
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Thursday, March 13, 1997 12:16 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[2]: Write Posting and Ordering

David,

Thanks for reading over my lengthy ramblings ... some more comments 
embedded below.

Jerry

> Jerry,
  
> Good analysis.  Just had a couple of questions which I embedded in the snippet
> below.
  
> David
  
> Jerry Hauck <Jerry_Hauck@ccm.sc.intel.com> Wrote:
> |
> --- lots of good stuff was here ----
> |
> | Conclusion
> | ==========
> | To balance implementation reality, performance, and consistency, I
> | feel the following rules are adequate and sufficient to deliver the 
> | ordering relationships shown in the table immediately above.
> |
> | 1) Posting by Region:
> |
> |   Region A: No Posting
> |   Region B: Posting Allowed
> |   Region C: No Posting
> |   Region D: Posting Allowed (for trusted nodes)
> |   Region E: No Posting
> |
> | 2) Ordering:
> |
> |   2.1) Read and write requests within the Asynchronous Request FIFO
> |   SHALL NOT pass ANY posted writes, whether posted in the Physical OR 
> |   Asynchronous Request FIFO's.
  
> Just to make sure I'm clear on this.  Are you saying that if I have a
> posted write for D then I can't update the status of the AR request or
> response buffers to indicate the arrival of a packet that occured after D 
> until D is written to memeory? (my question isn't all that clear either is
> it.)

Essentially I agree with you, but I first want to write a really long 
sentence.  The fundamental requirement is that if a write has been posted 
(ack_complete) to D, then no subsequent process which was directly or 
indirectly invoked due to the apparent completion of that write should be 
allowed to reference the address of the posted write until the posted data 
has actually been delivered to memory.  (Further restrictions required if D 
allows side-effects.)

To achieve this in a realistic implementation, we make some obvious choices.  
From an OHCI hardware perspective, we have no idea which subsequent 
subactions received from the bus were directly or indirectly triggered by the 
ack_complete of the posted write.  So, we simply assume that ALL subsequently 
received subactions were triggered by the ack_complete, and we must make sure 
that they do not "pass" the posted write data.  As you suggest above, one way 
to enforce the no passing zone is to not inform software that new packets are 
available until the posted write actually completes.

So, the implementation you describe above is sufficient, but not necessary 
since other solutions exist.  I like yours.

WARNING: A digression ahead.
I note that you snuck something new in: my version of rules 2.1 and 2.2 
described when and if REQUESTS could pass posted writes.  Your recap extended 
the discussion to REQUESTS and RESPONSES which raises an interesting 
question.  Can an ack_complete issued by OHCI for a posted write trigger an 
external node to send a RESPONSE to OHCI?  If so, then I probably should 
amend some of the ordering rules to preclude responses from passing posted 
writes in some of the FIFO's.  A semi-stupid (meaning I have no idea what I'm 
talking about) example:

  Assume two devices A&B, and that at least A is OHCI compliant.  Device B 
  implements a write-back cache of a portion of A's memory space.  A wants to 
  invalidate B's cache before operating on the local image in A's host 
  memory.  1394 traffic:
  
    1) A sends request subaction to B asking for a write-back and 
    invalidation of all modified lines
    
    2) B issues a series of write requests to A for all of the modified 
    lines.  A posts the writes, responding with one or more ack_completes.
    
    3) B responds to A's initial request, claiming the write-back is 
    complete.
    
    4) A operates on data in the local image of the cache.
    
  In this hypothetical case, an ack_complete in step 2 triggered a response 
  from B to A.  If that response "passes" the posted data in A, we have a 
  coherency issue as A begins to operate on the image.
    
  
> |
> |   2.2) Within the Physical Request FIFO, read requests MAY coherently
> |   pass posted writes, but writes requests and posted writes SHALL NOT
> |   pass other writes posted in the Physical Request FIFO.  Physical
> |   read and write requests MAY pass writes posted to the Asynchronous 
> |   Request FIFO.
> |
> | 3) Restrictions on Use by Region:
> |
> |   Region A: Address may have side-effects
> |   Region B: Writes shall not have 1394 visible side-effects
  
> I think this is a tough one. The write has an effect.  That effect will, in 
> many cases, have another effect that will visible on 1394 (i.e., a
> "side-effect".) I think the intent is to preserve causality but I don't
> know of a good way to state it.

You are right and I struggled with this when I wrote it.  By 1394 visible 
side-effect, I think I'm referring to any side-effect upon which a 
subsequently issued (relative to a posted write) subaction relies upon.  Does 
the concept of "causality" describe this?
  
> |   Region C & D: Addresses shall not have side-effects
> |   Region E: Reads shall not have 1394 visible side-effects
> |

Jerry Hauck
Intel Corp.
408-765-5528
From:	DavidW@bangate.compaq.com
Sent:	Thursday, March 13, 1997 8:25 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: different speed for isochronous channel

Currently, one cannot concatenate an S100 packet onto a higher speed packet 
(it works for some PHYs but not all of them.)  Since the HC can't sort the 
context by speed (the speed code is in the descriptor) the host controller 
(link) will have to look at the speed code of each iso packet. If a packet is 
not S100 then it can be concatenated onto any packet.  If the packet is S100 
and the previous packet was S100, then the packet can be concatenated.  If the 
packet is S100 and the previous packet was not S100 then the link will have to 
release the bus and rearbitrate (we are going to have to make sure that 1394A 
PHYs support this behavior.)

This indicates yet another reason for getting rid of S100 stuff.  Not only 
does it take a disproportionate amount of bus time for the data transfer, it 
also causes excess bus overhead.  Tell all your friends who do CE stuff to get 
rid of S100 in all their designs  (the proceeding was an unpaid political 
announcement.)

David

jyshiuan@sis.com.tw (jyshiuan) Wrote:
| 
| Hi all:
| 
|   I have a question about the isochronous channel transmition.
|   If I have 2 isochronous channels ready to transmition.
|   The speed for channel A is 100, and channel B is 200.
| 
|   How do the OHCI to request the PHY?
|   Does it request using spd 100, and then concatenate these two packets?
|   or request two times using different speed?
| 
|   Thanks for your time and answer,
| 
| ===============================================
| Jing-Yeh Shiuan
| Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.
| E-mail:     jyshiuan@sis.comp.tw
| Phone:     886-3-5774922 ext 4302
| Fax:          886-3-5790651
| Email:      jyshiuan@sis.com.tw
| Address: No 16, Creation Rd 1, 
|                  Science-based Industrial Park,
|                  Hsin Chu, Taiwan, R. O. C.
| ==============================================
| 
| 
From:	walter fry [Walter=Fry%Portable%PCPD=Hou@bangate.compaq.com]
Sent:	Friday, March 14, 1997 7:32 AM
To:	1394ohci-l@austin.ibm.com
Subject:	unsubscribe please

From:	rhsheu@sis.com.tw
Sent:	Monday, March 17, 1997 5:09 AM
To:	1394ohci-l@austin.ibm.com
Cc:	shuming@sis.com.tw; daisy@sis.com.tw; rhsheu@sis.com.tw
Subject:	PCI  Command Register MA bit

OHCI spec section B.3.1: "If the MA is reset to 1'b0, the Host Controller
can no longer respond to any software command addressed to it and interrrupt
generation is halted."

1. Could you specify the situations that the MA bit will be reset to zero ?
2. When the MA bit is set to one again, is the previous interrupt
information(stored in  IntEvent register, IsoXmitIntEvent,
IsoRecvIntEvent,....) still valid ?  


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ruey-Horng Sheu
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 432e
Fax: 886-3-5778774
Email: rhsheu@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	Tsai Chia-Yu [cytsai@sun13.via.com.tw]
Sent:	Monday, March 17, 1997 6:57 PM
To:	1394ohci-l@austin.ibm.com
Cc:	P1394@sun.com
Subject:	registeration

Dear Sir:

This mail is from VIA Technologies, INC which is developing the P1394
project.
Please append below emal address to your email list to reflect.
Thank you.

cytsai@via.com.tw
chuan@via.com.tw
-- 
    -~-~-~-~-~-~-~-~-~-~-~-~-~-~
     Chia-Yu Tsai
     Software Engineer
     VIA Technologies, INC
     Tel: 886-2-218-5452 x 356
     Fax: 886-2-218-7527
     Email: cytsai@via.com.tw
    -~-~-~-~--~-~-~-~-~-~-~-~-~-
From:	Vilas Bhade [vilas@wipro.com]
Sent:	Monday, March 17, 1997 7:04 PM
To:	1394ohci-l@austin.ibm.com
Subject:	registeration


Subscribe Me.
From:	Kazushige Nakayama [kazu@oddc.sps.mot.com]
Sent:	Monday, March 17, 1997 8:29 PM
To:	cytsai@sun13.via.com.tw
Cc:	1394ohci-l@austin.ibm.com; P1394@sun.com
Subject:	Re: registeration 

POPI level: MOTOROLA INTERNAL USE ONLY
Lines: 34
Date: Tue, 18 Mar 1997 13:28:58 +0900
Sender: kazu@yakisoba.sps.mot.com

>>>>> Tsai Chia-Yu-san writes:

  > Dear Sir:
  > This mail is from VIA Technologies, INC which is developing the P1394
  > project.
  > Please append below emal address to your email list to reflect.
  > Thank you.

  > cytsai@via.com.tw
  > chuan@via.com.tw
kazu@oddc.sps.mot.com
  > -- 
  >     -~-~-~-~-~-~-~-~-~-~-~-~-~-~
  >      Chia-Yu Tsai
  >      Software Engineer
  >      VIA Technologies, INC
  >      Tel: 886-2-218-5452 x 356
  >      Fax: 886-2-218-7527
  >      Email: cytsai@via.com.tw
  >     -~-~-~-~--~-~-~-~-~-~-~-~-~-



Regards,

Kaazushige Nakayama,
                                                     r13241@email.sps.mot.com
Osaka Design and Development Center,                 kazu@oddc.sps.mot.com
Semiconductor Products Division                      Tel: +81-6-305-7278
Nippon Motorola Ltd.                                 Fax: +81-6-305-7251 
5-5-15, Nishinakajima, Yodogawa-ku, Osaka 532 Japan	 
----------------------------------------------------------------------------
From:	John Nels Fuller
Sent:	Tuesday, March 18, 1997 12:18 AM
To:	1394ohci-l@austin.ibm.com; rhsheu@sis.com.tw
Cc:	shuming@sis.com.tw; daisy@sis.com.tw
Subject:	RE: PCI  Command Register MA bit

When an OS such as Windows NT boots the PCI enumerator must discover the
size of the memory allocation that is required by the device.  Since
this has to be done before any specific device driver is loaded for the
device it must rely on only PCI generic code to do this.  The following
procedure is followed:
	Read and Save current value of the BAR
	Clear MA
	Write 32h'FFFFFFFF to BAR
	Read BAR to determine size of allocation
	Restore original value of BAR
	Set MA
The device may still have a BIOS driver at this point and must not cause
an interrupt while MA is clear because it is not mapped where the BIOS
thinks that it is.  We can't just disable interrupt because sometimes
the OEM routes the interrupt to SMI when the BIOS controls the device
and SMI is not maskable.

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> ----------
> From: 	rhsheu@sis.com.tw[SMTP:rhsheu@sis.com.tw]
> Sent: 	Monday, March 17, 1997 5:09 AM
> To: 	1394ohci-l@austin.ibm.com
> Cc: 	shuming@sis.com.tw; daisy@sis.com.tw; rhsheu@sis.com.tw
> Subject: 	PCI  Command Register MA bit
> 
> OHCI spec section B.3.1: "If the MA is reset to 1'b0, the Host
> Controller
> can no longer respond to any software command addressed to it and
> interrrupt
> generation is halted."
> 
> 1. Could you specify the situations that the MA bit will be reset to
> zero ?
> 2. When the MA bit is set to one again, is the previous interrupt
> information(stored in  IntEvent register, IsoXmitIntEvent,
> IsoRecvIntEvent,....) still valid ?  
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Ruey-Horng Sheu
> Design Engineer
> Basic Technology Group
> Silicon Intergrated Systems Corp.
> Tel: 886-3-5774922 x 432e
> Fax: 886-3-5778774
> Email: rhsheu@sis.com.tw
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
From:	Mike N Bryan [Mike_N_Bryan@notes.seagate.com]
Sent:	Tuesday, March 18, 1997 1:08 AM
To:	Tsai Chia-Yu
Cc:	1394ohci-l; P1394
Subject:	Re: registeration

What in the world does this mean? You're a little late to develop a P1394 
project - its already been approved.
To: 1394ohci-l @ austin.ibm.com @ INTERNET
cc: P1394 @ Sun.COM @ INTERNET (bcc: Mike N Bryan)
From: cytsai @ sun13.via.com.tw (Tsai Chia-Yu) @ INTERNET
Date: 03/18/97 10:56:51 AM PST
Subject: registeration

Dear Sir:

This mail is from VIA Technologies, INC which is developing the P1394
project.
Please append below emal address to your email list to reflect.
Thank you.

cytsai@via.com.tw
chuan@via.com.tw
-- 
    -~-~-~-~-~-~-~-~-~-~-~-~-~-~
     Chia-Yu Tsai
     Software Engineer
     VIA Technologies, INC
     Tel: 886-2-218-5452 x 356
     Fax: 886-2-218-7527
     Email: cytsai@via.com.tw
    -~-~-~-~--~-~-~-~-~-~-~-~-~-

 
From:	Dick Scheel [dicks@lsi.sel.sony.com]
Sent:	Tuesday, March 18, 1997 10:31 AM
To:	Mike N Bryan
Cc:	1394ohci-l; P1394
Subject:	Re: registeration

Mike:  It means that Mr. Tsai is not quite perfect in his English.  I think
most of us understood that he meant that they are working on a project that
will use 1394.

Regards,
Dick Scheel / Sony

At 09:08 AM 3/18/97, Mike N Bryan wrote:
>What in the world does this mean? You're a little late to develop a P1394 
>project - its already been approved.
>
>To: 1394ohci-l @ austin.ibm.com @ INTERNET
>cc: P1394 @ Sun.COM @ INTERNET (bcc: Mike N Bryan)
>From: cytsai @ sun13.via.com.tw (Tsai Chia-Yu) @ INTERNET
>Date: 03/18/97 10:56:51 AM PST
>Subject: registeration
>
>Dear Sir:
>
>This mail is from VIA Technologies, INC which is developing the P1394
>project.
>Please append below emal address to your email list to reflect.
>Thank you.
>
>cytsai@via.com.tw
>chuan@via.com.tw
>-- 
>    -~-~-~-~-~-~-~-~-~-~-~-~-~-~
>     Chia-Yu Tsai
>     Software Engineer
>     VIA Technologies, INC
>     Tel: 886-2-218-5452 x 356
>     Fax: 886-2-218-7527
>     Email: cytsai@via.com.tw
>    -~-~-~-~--~-~-~-~-~-~-~-~-~-
=================================================================
| Dick Scheel                   | Tel: (408) 955-4295           |
| Sony US Research Labs         | Fax: (408) 955-5180           |
| LSI Systems Laboratory        | email: dicks@lsi.sel.sony.com |
| 3300 Zanker Rd.   M/S SJ3D3   |                               |
| San Jose, CA  95134-1940      | O-                            |
=================================================================
From:	Rob Lash [bassman@apple.com]
Sent:	Tuesday, March 18, 1997 11:52 AM
To:	1394ohci-l@austin.ibm.com
Subject:	unsubscribe

unsubscribe


----------------------------------------------------------------
Rob Lash   MS:35-OEM       When you get to the fork in the road
Apple Computer, Inc.       ... Take it!
One Infinite Loop                                  - Yogi Berra
Cupertino, CA 95014
(408) 974-3889
bassman@apple.com
----------------------------------------------------------------

From:	yehiel engel [YENGEL@HAIFASC3.HAIFA.IBM.COM]
Sent:	Wednesday, March 19, 1997 3:49 AM
To:	1394ohci-l@austin.ibm.com
Cc:	PELED@HAIFASC3.HAIFA.IBM.COM
Subject:	More questions

========================

Hello all.
I have two questions concerning the OHCI draft 0.92.
1. How can we add vendor defined registers to the
   open HCI register space. According to the spec (page 25):
   "The 1394 open HCI's register occupy a 2048 byte address
    space", "All address within this 2K address are reserved
    for OpenHCI and not vendor defined registers".
    I think that extra portion of space should be allocate
    for the OpenHCI registers (e.g. the OpenHCI controller should ask
    for 4K  instead of 2K). The added portion should be used
    for vendor defined registers.
 2. What is purpose for the GUID ROM register?. This register contains
    the bus_info_block which is loaded automatically
    on hardware reset. As I understand it, bus_info_block is the only
    information placed on that ROM (other information may be added using
    expansion ROM on the host bus).

Any comment will be appreciated.

Regards
Yehiel Engel
From:	daisy@sis.com.tw
Sent:	Wednesday, March 19, 1997 4:38 AM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Cc:	shchuang@sis.com.tw; cmlin@sis.com.tw; mjlu@sis.com.tw; jyshiuan@sis.com.tw; daisy@sis.com.tw
Subject:	questions about cycleLost Event

Hi, all,

I have some questions about cycleLost event on OHCI092, Table 6-1. It 
states as folllows,

[ cycleLost indicates that an expected cycle start has not been received.
This will be set whenever a cycle start is not received immediately after
the first subaction gap after the cycleSynch event, ot if an arbitration 
reset gap is detected after a cycleSynch event without an intervening cycle
start.]

My question are, 
1. when the host controller itself is a cycle master, will it set this
   event bit when it "want" to send a cycle start packet but it can't?
   Such as in bus reset period ?

2. when the cycleLost resulted by the bus reset, this bit will not be
   set according to the definition of Table 6-1, because there is no 
   subaction gap or arbitration reset gap during bus reset period. 
   For example, when a bus reset period crosses cycle N-1, cycle N, and 
   cycle N+1, between the two cycle sync. of cycle N and cycle N+1, 
   no cycle start packet is sent, thus no isochronous cycle between these 
   two cycle sync.. 
   In the definition of section 9.3.3, I think the above condition
   is a truely cycleLost which is conflict with the definition of 
   Table 6-1. Have I missed anything ?

I appreciate if someone can clearify the questions.
 
Regards,

Y.J. Chao
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================
From:	joels@austin.ibm.com
Sent:	Wednesday, March 19, 1997 5:57 AM
To:	1394ohci-l@austin.ibm.com
Subject:	unsubscribe





  unsubscribe

From:	John Nels Fuller
Sent:	Wednesday, March 19, 1997 10:45 AM
To:	1394ohci-l@austin.ibm.com; 'yehiel engel'
Cc:	PELED@HAIFASC3.HAIFA.IBM.COM
Subject:	RE: More questions

see below:
_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> ----------
> From: 	yehiel engel[SMTP:YENGEL@HAIFASC3.HAIFA.IBM.COM]
> Sent: 	Wednesday, March 19, 1997 3:49 AM
> To: 	1394ohci-l@austin.ibm.com
> Cc: 	PELED@HAIFASC3.HAIFA.IBM.COM
> Subject: 	More questions
> 
> ========================
> 
> Hello all.
> I have two questions concerning the OHCI draft 0.92.
> 1. How can we add vendor defined registers to the
>    open HCI register space. According to the spec (page 25):
>    "The 1394 open HCI's register occupy a 2048 byte address
>     space", "All address within this 2K address are reserved
>     for OpenHCI and not vendor defined registers".
>     I think that extra portion of space should be allocate
>     for the OpenHCI registers (e.g. the OpenHCI controller should ask
>     for 4K  instead of 2K). The added portion should be used
>     for vendor defined registers.
> 
If the allocation size for the register space is more than 2K then the
extra space is vendor unique area.  Alternately, you could specify
another allocation by using another BAR in PCI config space.  Either of
these methods may be used to get vendor unique registers.

>  2. What is purpose for the GUID ROM register?. This register contains
>     the bus_info_block which is loaded automatically
>     on hardware reset. As I understand it, bus_info_block is the only
>     information placed on that ROM (other information may be added
> using
>     expansion ROM on the host bus).
> 
The bus_info_block is the only *required* information in the GUID ROM.
Some OEM's may wish to put other per system data in the GUID ROM as
opposed to having flash for system ROM.


> Any comment will be appreciated.
> 
> Regards
> Yehiel Engel
> 
From:	Yehuda Peled [peled@haifa.vnet]
Sent:	Tuesday, March 18, 1997 12:04 PM
To:	John Nels Fuller
Cc:	1394ohci-l@austin.ibm.com; 'yehiel engel'
Subject:	Re: More questions

John,
Thanks for your response.
Please see my comments on the second question.

Thanks
 Yehuda

John Nels Fuller wrote:
> 
> see below:
> _____________________
> John Nels Fuller
> Software Design Engineer, Windows NT
> Microsoft Corporation
> One Microsoft Way
> Redmond, WA   98052-6399
> Voice: (206) 703-3863
> Fax: (206) 93 MSFAX
> 
> > ----------
> > From:         yehiel engel[SMTP:YENGEL@HAIFASC3.HAIFA.IBM.COM]
> > Sent:         Wednesday, March 19, 1997 3:49 AM
> > To:   1394ohci-l@austin.ibm.com
> > Cc:   PELED@HAIFASC3.HAIFA.IBM.COM
> > Subject:      More questions
> >
> > ========================
> >
> > Hello all.
> > I have two questions concerning the OHCI draft 0.92.
> > 1.  How can we add vendor defined registers to the
> >    open HCI register space. According to the spec (page 25):
> >    "The 1394 open HCI's register occupy a 2048 byte address
> >     space", "All address within this 2K address are reserved
> >     for OpenHCI and not vendor defined registers".
> >     I think that extra portion of space should be allocate
> >     for the OpenHCI registers (e.g. the OpenHCI controller should ask
> >     for 4K  instead of 2K).  The added portion should be used
> >     for vendor defined registers.
> >
> If the allocation size for the register space is more than 2K then the
> extra space is vendor unique area.  Alternately, you could specify
> another allocation by using another BAR in PCI config space.  Either of
> these methods may be used to get vendor unique registers.
> 
> > 2.  What is purpose for the GUID ROM register?  This register contains
> >     the bus_info_block which is loaded automatically
> >     on hardware reset. As I understand it, bus_info_block is the only
> >     information placed on that ROM (other information may be added
> > using
> >     expansion ROM on the host bus).
> >
> The bus_info_block is the only *required* information in the GUID ROM.
> Some OEM's may wish to put other per system data in the GUID ROM as
> opposed to having flash for system ROM.
> 

Section B.5 in the HCI spec defines the use of a PCI expansion ROM for
1394 OpenHCI.  If the user want to allow the software to read from the
ROM then it should use the PCI expansion ROM mechanisim.The PCI spec
defines an expansion ROM base address register that is used to map the
ROM to the PCI memory address space.  The software may use PCI memory
read transaction to read the expansion ROM.
It is not clear why the HCI need to define another mechanism for reading
the ROM.
Maybe it is a left over from the days that the HC had interface to a
serial ROM.

> > Any comment will be appreciated.
> >
> > Regards
> > Yehiel Engel
> >
From:	John Nels Fuller
Sent:	Wednesday, March 19, 1997 12:17 PM
To:	'Yehuda Peled'
Cc:	1394ohci-l@austin.ibm.com; 'yehiel engel'
Subject:	RE: More questions

The GUID store is not necessarily the same as the expansion ROM.  The
expansion ROM also is usually not required nor wanted for a motherboard
implementation.
_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> ----------
> From: 	Yehuda Peled[SMTP:PELED@HAIFA.VNET.IBM.COM]
> Sent: 	Tuesday, March 18, 1997 12:03 PM
> To: 	John Nels Fuller
> Cc: 	1394ohci-l@austin.ibm.com; 'yehiel engel'
> Subject: 	Re: More questions
> 
> John,
> Thanks for your response.
> Please see my comments on the second question.
> 
> Thanks
>  Yehuda
> 
> John Nels Fuller wrote:
> >
> > see below:
> > _____________________
> > John Nels Fuller
> > Software Design Engineer, Windows NT
> > Microsoft Corporation
> > One Microsoft Way
> > Redmond, WA   98052-6399
> > Voice: (206) 703-3863
> > Fax: (206) 93 MSFAX
> >
> > > ----------
> > > From:         yehiel engel[SMTP:YENGEL@HAIFASC3.HAIFA.IBM.COM]
> > > Sent:         Wednesday, March 19, 1997 3:49 AM
> > > To:   1394ohci-l@austin.ibm.com
> > > Cc:   PELED@HAIFASC3.HAIFA.IBM.COM
> > > Subject:      More questions
> > >
> > > ========================
> > >
> > > Hello all.
> > > I have two questions concerning the OHCI draft 0.92.
> > > 1.  How can we add vendor defined registers to the
> > >    open HCI register space. According to the spec (page 25):
> > >    "The 1394 open HCI's register occupy a 2048 byte address
> > >     space", "All address within this 2K address are reserved
> > >     for OpenHCI and not vendor defined registers".
> > >     I think that extra portion of space should be allocate
> > >     for the OpenHCI registers (e.g. the OpenHCI controller should
> ask
> > >     for 4K  instead of 2K).  The added portion should be used
> > >     for vendor defined registers.
> > >
> > If the allocation size for the register space is more than 2K then
> the
> > extra space is vendor unique area.  Alternately, you could specify
> > another allocation by using another BAR in PCI config space.  Either
> of
> > these methods may be used to get vendor unique registers.
> >
> > > 2.  What is purpose for the GUID ROM register?  This register
> contains
> > >     the bus_info_block which is loaded automatically
> > >     on hardware reset. As I understand it, bus_info_block is the
> only
> > >     information placed on that ROM (other information may be added
> > > using
> > >     expansion ROM on the host bus).
> > >
> > The bus_info_block is the only *required* information in the GUID
> ROM.
> > Some OEM's may wish to put other per system data in the GUID ROM as
> > opposed to having flash for system ROM.
> >
> 
> Section B.5 in the HCI spec defines the use of a PCI expansion ROM for
> 1394 OpenHCI.  If the user want to allow the software to read from the
> ROM then it should use the PCI expansion ROM mechanisim.The PCI spec
> defines an expansion ROM base address register that is used to map the
> ROM to the PCI memory address space.  The software may use PCI memory
> read transaction to read the expansion ROM.
> It is not clear why the HCI need to define another mechanism for
> reading
> the ROM.
> Maybe it is a left over from the days that the HC had interface to a
> serial ROM.
> 
> > > Any comment will be appreciated.
> > >
> > > Regards
> > > Yehiel Engel
> > >
> 
From:	Dave Marshall [Dave_Marshall@aussmtp.austin.ibm.com]
Sent:	Wednesday, March 19, 1997 8:58 AM
To:	1394ohci-l
Subject:	unsubscribe

unsubscribe
From:	PJohansson@aol.com
Sent:	Wednesday, March 19, 1997 6:49 PM
To:	peled@haifa.vnet; John Nels Fuller
Cc:	1394ohci-l@austin.ibm.com; YENGEL@haifasc3.haifa.ibm.com
Subject:	Re: More questions

In a message dated 97-03-19 15:48:26 EST, peled@haifa.vnet (Yehuda Peled)
writes:

<<Section B.5 in the HCI spec defines the use of a PCI expansion ROM for 1394
OpenHCI.  If the user want to allow the software to read from the
 ROM then it should use the PCI expansion ROM mechanisim.The PCI spec defines
an expansion ROM base address register that is used to map the ROM to the PCI
memory address space.  The software may use PCI memory read transaction to
read the expansion ROM. It is not clear why the HCI need to define another
mechanism for reading the ROM.

Maybe it is a left over from the days that the HC had interface to a serial
ROM.>>

This is an unfortunate case where ROM is being confused with ROM (see what I
mean?).

OpenHCI should be more explicit...

The OpenHCI registers that provide the values visible on Serial Bus for the
bus information block are there for two reasons: a) unforgeable identity of
the node (EUI-64) and b) hardware-assisted (i.e., efficient) access to
portions of configuration ROM that are expected to attract a HIGH number of
quadlet reads subsequent to a bus reset.

So the ROM in this case is a portion of Serial Bus CSR address space that is
"configuration ROM"---distinct from executable ROM.

The PCI expansion ROM is, I believe, for executable ROM (likely not visible
from Serial Bus). Simple bus manager code, isochronous resource manager code,
etc., might reside here for those cases where a loaded software driver
doesn't provide these functions for OpenHCI. Perhaps some day OpenHCI is
boot-capable, once the problem of identifying which SBP-2 disk contains the
boot image has been solved.

Does this clear up the difference, Yehuda?

Maybe OpenHCI 0.9x can elaborate on this topic.

Regards,

Peter Johansson
From:	mjlu@sis.com.tw
Sent:	Wednesday, March 19, 1997 7:24 PM
To:	1394ohci-l@austin.ibm.com
Subject:	How to adjust the host side cycle timer in ITDMA

Hi,all:

In ITDMA, if the cycleMatch field is programmed with value N, it intends to 
transmit the first packet in the context at the period of after cycle start 
N has been sent or received, and before cycle start N+1 is sent or received. 
But since the link side cycle timer may be changed and the host side cycle 
timer may be 2 cycles ahead of link side, how to adjust the host side cycle 
timer ? Does it need to keep track of the link side cycle timer precisely or 
it is permitted to have few cycles deviation?

I would very much appreciate if someone can clarify this question.

From:	shuming@sis.com.tw
Sent:	Thursday, March 20, 1997 4:02 AM
To:	1394ohci-l@austin.ibm.com
Subject:	resCount in IR Buffer-Fill mode

Hi, all,

  Page75 para 5 of OHCI0.92, it says:"Software must initialize 
resCount to the value of reqCount.". My question is: Shall software 
also need to initialize resCount to the value of reqCount in IR 
Buffer-Fill mode?

  Thanks for your time and answer.
***************************************************************
Shu-Ming Liu                                                 
Software Engineer                                            
Software Design Department                                   
Silicon Integrated Systems Corp.                             
Phone 886-35-774922 ext 4157                                 
Fax   886-35-790651                                          

mailto
shuming@sis.com.tw                                  
***************************************************************
From:	John Nels Fuller
Sent:	Thursday, March 20, 1997 12:23 AM
To:	1394ohci-l@austin.ibm.com; mjlu@sis.com.tw
Subject:	RE: How to adjust the host side cycle timer in ITDMA

We are in a process of discussing this issue and will have an answer for
you in a few days.

Thanks for your patience.

__________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX



> ----------
> From: 	mjlu@sis.com.tw[SMTP:mjlu@sis.com.tw]
> Sent: 	Wednesday, March 19, 1997 7:23 PM
> To: 	1394ohci-l@austin.ibm.com
> Subject: 	How to adjust the host side cycle timer in ITDMA
> 
> Hi,all:
> 
> In ITDMA, if the cycleMatch field is programmed with value N, it
> intends to 
> transmit the first packet in the context at the period of after cycle
> start 
> N has been sent or received, and before cycle start N+1 is sent or
> received. 
> But since the link side cycle timer may be changed and the host side
> cycle 
> timer may be 2 cycles ahead of link side, how to adjust the host side
> cycle 
> timer ? Does it need to keep track of the link side cycle timer
> precisely or 
> it is permitted to have few cycles deviation?
> 
> I would very much appreciate if someone can clarify this question.
> 
> 
From:	Yehuda Peled [peled@haifa.vnet]
Sent:	Thursday, March 20, 1997 2:51 AM
To:	PJohansson@aol.com; John Nels Fuller
Cc:	1394ohci-l@austin.ibm.com; YENGEL@haifasc3.haifa.ibm.com
Subject:	Re: More questions

Peter & John,

Thanks for your notes.
I understand it now.
I still have one comment.
The ROM structure is not defined, so this feature can not be used by a
common mini-port driver.
I thought that the purpose of the OHCI is to enable the use of a common 
mini-port driver.

Thanks
 Yehuda

PJohansson@aol.com wrote:
> 
> In a message dated 97-03-19 15:48:26 EST, peled@haifa.vnet (Yehuda Peled)
> writes:
> 
> <<Section B.5 in the HCI spec defines the use of a PCI expansion ROM for 1394
> OpenHCI.  If the user want to allow the software to read from the
>  ROM then it should use the PCI expansion ROM mechanisim.The PCI spec defines
> an expansion ROM base address register that is used to map the ROM to the PCI
> memory address space.  The software may use PCI memory read transaction to
> read the expansion ROM. It is not clear why the HCI need to define another
> mechanism for reading the ROM.
> 
> Maybe it is a left over from the days that the HC had interface to a serial
> ROM.>>
> 
> This is an unfortunate case where ROM is being confused with ROM (see what I
> mean?).
> 
> OpenHCI should be more explicit...
> 
> The OpenHCI registers that provide the values visible on Serial Bus for the
> bus information block are there for two reasons: a) unforgeable identity of
> the node (EUI-64) and b) hardware-assisted (i.e., efficient) access to
> portions of configuration ROM that are expected to attract a HIGH number of
> quadlet reads subsequent to a bus reset.
> 
> So the ROM in this case is a portion of Serial Bus CSR address space that is
> "configuration ROM"---distinct from executable ROM.
> 
> The PCI expansion ROM is, I believe, for executable ROM (likely not visible
> from Serial Bus). Simple bus manager code, isochronous resource manager code,
> etc., might reside here for those cases where a loaded software driver
> doesn't provide these functions for OpenHCI. Perhaps some day OpenHCI is
> boot-capable, once the problem of identifying which SBP-2 disk contains the
> boot image has been solved.
> 
> Does this clear up the difference, Yehuda?
> 
> Maybe OpenHCI 0.9x can elaborate on this topic.
> 
> Regards,
> 
> Peter Johansson
From:	Hsu jung-tsan [zung@via.com.tw]
Sent:	Wednesday, March 19, 1997 2:57 PM
To:	1394ohci-l@austin.ibm.com; p1394@sun.com
Subject:	Subscribe

Subscribe 


	~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	Jung-Tsan Hsu
	ASIC engineer
	VIA Technology, INC.
        E-mail : zung@via.com.tw
	TEL : 886-2-218-5452 EXT. 304
	FAX : 886-2-218-5453
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	rhsheu@sis.com.tw
Sent:	Friday, March 21, 1997 5:21 AM
To:	1394ohci-l@austin.ibm.com
Subject:	PCI Global Swap

Hi,

OHCI spec B.4: "PCI Global Swap Bit ----- When this bit is b'1, all quadlets
read from and written to the PCI interface are byte swapped. PCI addresses,
such as expansion ROM and PCI config registers, are unaffected by this bit
(they are not byte swapped under any circumstances)."

Could you specify "PCI addresses" more explicit ?
 If the data in the PCI bus from 31 to 0 is  32'h1234_5678 
 and the PCIGlobalSwap = 1, 
 what is the data in the OHCI OP registers
 what is the data in the PCI CFG registers.


From:	DavidW@bangate.compaq.com
Sent:	Friday, March 21, 1997 8:49 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: resCount in IR Buffer-Fill mode

I believe it should/shall for the same reason that it initializes it for AR.

David Wooten

shuming@sis.com.tw Wrote:
| 
| Hi, all,
| 
|   Page75 para 5 of OHCI0.92, it says:"Software must initialize 
| resCount to the value of reqCount.". My question is: Shall software 
| also need to initialize resCount to the value of reqCount in IR 
| Buffer-Fill mode?
| 
|   Thanks for your time and answer.
| ***************************************************************
| Shu-Ming Liu                                                 
| Software Engineer                                            
| Software Design Department                                   
| Silicon Integrated Systems Corp.                             
| Phone 886-35-774922 ext 4157                                 
| Fax   886-35-790651                                          
| 
mailto
shuming@sis.com.tw                                  
| ***************************************************************
| 
From:	cylin@sis.com.tw
Sent:	Sunday, March 23, 1997 7:48 PM
To:	1394ohci-l@austin.ibm.com
Subject:	xferStatus for AR/IR

Hi,

According to OHCI0.92, a packet straddling more then one buffer will require
two status write cycles, one for the final buffer's descriptor
and the other for the first buffer's descriptor. For the latter case, the
spec. said in page 75, "update xferStatus and resCount into the first
buffer's descriptor". Is this xferStatus the contents of 
ContextControl(15:0) when the first buffer is filled or those when the
entire packet is received- the same as xferStatus of the final buffer?

Thanks for your time and answer,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	Hsu jung-tsan [zung@via.com.tw]
Sent:	Sunday, March 23, 1997 1:16 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Subscribe

Subcribe

	~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	Jung-Tsan Hsu
	ASIC engineer
	VIA Technology, INC.
        E-mail : zung@via.com.tw
	TEL : 886-2-218-5452 EXT. 304
	FAX : 886-2-218-5453
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	rhsheu@sis.com.tw
Sent:	Monday, March 24, 1997 1:00 AM
To:	1394ohci-l@austin.ibm.com
Cc:	rhsheu@sis.com.tw; jyshiuan@sis.com.tw
Subject:	GUID ROM register

John,

OHCI Spec 0.92 Section5.3 GUID ROM register:

addrReset: "This bit is set to one to reset the ROM address to zero. It must
be cleared for any reads."  While its Tag field is "rw".

If "it must be cleared for any reads" means "Hardware must clear this bit
when software read this register", how about change "rw" to "rwu or rs" ?

rdStart bit is a  case similiar to addrReset. Why do they use different "Tag"?

Thanks.
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ruey-Horng Sheu
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4323
Fax: 886-3-5778774
Email: rhsheu@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
From:	John Nels Fuller
Sent:	Monday, March 24, 1997 11:27 AM
To:	'cylin@sis.com.tw'; 1394ohci-l@austin.ibm.com
Subject:	RE: xferStatus for AR/IR

The status should be the value of ContextControl[15:0] at the time it is
written, probably the same for both the first and last buffers in this
case.

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> -----Original Message-----
> From:	cylin@sis.com.tw [SMTP:cylin@sis.com.tw]
> Sent:	Sunday, March 23, 1997 7:48 PM
> To:	1394ohci-l@austin.ibm.com
> Subject:	xferStatus for AR/IR
> 
> Hi,
> 
> According to OHCI0.92, a packet straddling more then one buffer will
> require
> two status write cycles, one for the final buffer's descriptor
> and the other for the first buffer's descriptor. For the latter case,
> the
> spec. said in page 75, "update xferStatus and resCount into the first
> buffer's descriptor". Is this xferStatus the contents of 
> ContextControl(15:0) when the first buffer is filled or those when the
> entire packet is received- the same as xferStatus of the final buffer?
> 
> Thanks for your time and answer,
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Chien-Yuh Lin
> Design Engineer
> Basic Technology Group
> Silicon Intergrated Systems Corp.
> Tel: 886-3-5774922 x 4326
> Fax: 886-3-5778774
> Email: cylin@sis.com.tw
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	shuming@sis.com.tw
Sent:	Tuesday, March 25, 1997 9:41 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Ack_type_error Condition

Hi, all, 

  I have a question about Ack_type_error condition.

  OHCI0.92 page 15, it says"ACK_TYPE_ERROR: A field in the request 
packet header was set to an unsupported or incorrect value, or....."

  My question is : If the extended_Tcode field of block read/write request is not 
ZERO, shall HC return ACK_TYPE_ERROR? Will this field be used for
some special purpose in the future?

Thanks for your time and answers. 
  
***************************************************************
Shu-Ming Liu                                                 
Software Engineer                                            
Software Design Department                                   
Silicon Integrated Systems Corp.                             
Phone 886-35-774922 ext 4157                                 
Fax   886-35-790651                                          

mailto
shuming@sis.com.tw                                  
***************************************************************
From:	Diana.Klashman@East.Sun.COM
Sent:	Tuesday, March 25, 1997 8:49 AM
To:	rhsheu@sis.com.tw
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: GUID ROM register

Some of us were discussing this very issue last week and yes,
this register does need some cleanup. 

In .93 the following changes will be made to section 5.3:
   - addrReset will be rsu
   - dataReady will be removed/deleted.
   - rdStart will be rsu.

The .93 version is currently planned to be released by April 4.

Thanks,
Diana


>From rhsheu@sis.com.tw Mon Mar 24 04:00:19 1997
>From: rhsheu@sis.com.tw (Ruey-Horng Sheu)
>
>John,
>
>OHCI Spec 0.92 Section5.3 GUID ROM register:
>
>addrReset: "This bit is set to one to reset the ROM address to zero. It must
>be cleared for any reads."  While its Tag field is "rw".
>
>If "it must be cleared for any reads" means "Hardware must clear this bit
>when software read this register", how about change "rw" to "rwu or rs" ?
>
>rdStart bit is a  case similiar to addrReset. Why do they use different "Tag"?
>
>Thanks.
> 
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Ruey-Horng Sheu
>Design Engineer
>Basic Technology Group
>Silicon Intergrated Systems Corp.
>Tel: 886-3-5774922 x 4323
>Fax: 886-3-5778774
>Email: rhsheu@sis.com.tw
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	cylin@sis.com.tw
Sent:	Tuesday, March 25, 1997 9:24 PM
To:	1394ohci-l@austin.ibm.com

Hi,

In OHCI0.92, page 103, last para. said "software must only use resCount
values when the corresponding xferStatus indicates the run bit is set to
one." However, page 15, last para. said "If software clears a 
ContextControl.run for an isochronous context while the Host Controller is
processing a packet for the context, the Host controller will continue to
receive or transmit the packet and update descriptor status." Since the
updated status will have run=0, the resCount and thus the packet will
not be valid to SW, then why requires HC to continue receive the packet
and update descriptor status? It seems that SW use the resCount when
active is set to one is more reasonable.

Thanks for your time and answer,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	mjlu@sis.com.tw
Sent:	Wednesday, March 26, 1997 3:21 AM
To:	1394ohci-l@austin.ibm.com
Subject:	questions about cycleLost event

Hi,all:

The questions about cycleLost event haven't been answered, I want to 
describe again and hope someone can answer them. Thanks a lot !!

The cycleLost event on OHCI092, Table 6-1. It states as folllows:

[ cycleLost indicates that an expected cycle start has not been received.
This will be set whenever a cycle start is not received immediately after
the first subaction gap after the cycleSynch event, ot if an arbitration 
reset gap is detected after a cycleSynch event without an intervening cycle
start.]

The questions are, 
1. when the host controller itself is a cycle master, will it set this
   event bit when it "want" to send a cycle start packet but it can't?
   Such as in bus reset period ?

2. when the cycleLost resulted by the bus reset, this bit will not be
   set according to the definition of Table 6-1, because there is no 
   subaction gap or arbitration reset gap during bus reset period. 
   For example, when a bus reset period crosses cycle N-1, cycle N, and 
   cycle N+1, between the two cycle sync. of cycle N and cycle N+1, 
   no cycle start packet is sent, thus no isochronous cycle between these 
   two cycle sync.. 
   In the definition of section 9.3.3, I think the above condition
   is a truely cycleLost which is conflict with the definition of 
   Table 6-1. Have I missed anything ?

Thanks for your time and answers.
From:	jyshiuan@sis.com.tw
Sent:	Wednesday, March 26, 1997 3:54 AM
To:	1394ohci-l@austin.ibm.com
Subject:	bus reset packet

hi all:

  I have a question about the bus reset packet.

  according to the OHCI 0.92, 8.4.2.3.
  it said:"Host controller inserts a synthesized PHY packet into the ARDMA.
  Request context buffer as soon as a bus reset condition is dected."

  My question is :
    if a bus reset condition occurs before the time that ARDMA request
context enables,
    will the bus reset packet inserts into the ARDMA buffer after the ARDMA
is enabled?

   because the bus reset packet is used to distinguish the packets before or
after bus reset,
   I think that the bus reset packet do not have to insert into the ARDMA FIFO.
   Am i correct?

  Thanks for your time and answer.

===============================================
Jing-Yeh Shiuan
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
E-mail:     jyshiuan@sis.comp.tw
Phone:     886-3-5774922 ext 4302
Fax:          886-3-5790651
Email:      jyshiuan@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan, R. O. C.
==============================================
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, March 26, 1997 9:50 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: questions about cycleLost event

Responses embedded below.

David


mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
| 
| Hi,all:
| 
| The questions about cycleLost event haven't been answered, I want to 
| describe again and hope someone can answer them. Thanks a lot !!
| 
| The cycleLost event on OHCI092, Table 6-1. It states as folllows:
| 
| [ cycleLost indicates that an expected cycle start has not been received.
| This will be set whenever a cycle start is not received immediately after
| the first subaction gap after the cycleSynch event, ot if an arbitration 
| reset gap is detected after a cycleSynch event without an intervening cycle
| start.]

A lost cycle is indicated if no cycleStart is sent/received between two 
successive cycleSynch events.  We think that this can be predicted by noticing 
that a cycle_start packet did not occur when it should have.   We should have  
made the definition clearer and then added the examples for when it can be 
predicted.

| 
| The questions are, 
| 1. when the host controller itself is a cycle master, will it set this
|    event bit when it "want" to send a cycle start packet but it can't?
|    Such as in bus reset period ?

HC will set this if it can't send cycle_start in an cycle.

| 
| 2. when the cycleLost resulted by the bus reset, this bit will not be
|    set according to the definition of Table 6-1, because there is no 
|    subaction gap or arbitration reset gap during bus reset period. 
|    For example, when a bus reset period crosses cycle N-1, cycle N, and 
|    cycle N+1, between the two cycle sync. of cycle N and cycle N+1, 
|    no cycle start packet is sent, thus no isochronous cycle between these 
|    two cycle sync.. 
|    In the definition of section 9.3.3, I think the above condition
|    is a truely cycleLost which is conflict with the definition of 
|    Table 6-1. Have I missed anything ?

No, you have not missed anything.  The rule should be stated as follows:

"A lost cycle is indicated when no cycle_start packet is sent/received between 
two successive  cycleSynch events.  A lost cycle can be predicted when a 
cycle_start packet does not immediately follow the first subaction gap after a 
cycleSynch event or if an arbitration reset gap is detected after a cycleSynch 
even without an intervening cycle start.  cycleLost may be set either when it 
occurs or when logic predicts that it will occur." 

| 
| Thanks for your time and answers.
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, March 26, 1997 9:08 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: 

You are correct.  SW will check the 'active' bit.  We had thought that we had 
purged all references indicating that SW would use the 'run' bit in xferStatus 
but...

David

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi,
| 
| In OHCI0.92, page 103, last para. said "software must only use resCount
| values when the corresponding xferStatus indicates the run bit is set to
| one." However, page 15, last para. said "If software clears a 
| ContextControl.run for an isochronous context while the Host Controller is
| processing a packet for the context, the Host controller will continue to
| receive or transmit the packet and update descriptor status." Since the
| updated status will have run=0, the resCount and thus the packet will
| not be valid to SW, then why requires HC to continue receive the packet
| and update descriptor status? It seems that SW use the resCount when
| active is set to one is more reasonable.
| 
| Thanks for your time and answer,
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	John Nels Fuller
Sent:	Wednesday, March 26, 1997 9:33 AM
To:	'cylin@sis.com.tw'; 1394ohci-l@austin.ibm.com
Subject:	RE: 

I think that the requirement on page 103 is wrong, it should be
"software must only use resCount values when the corresponding
xferStatus indicates the *active* bit is set to one."  When software
clears the run bit the active bit will stay one until the context
completes the current packet including writing the status.  I believe
that this has been our thinking for some time but we just haven't caught
all the references in the spec.

Thanks for pointing this out.

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> -----Original Message-----
> From:	cylin@sis.com.tw [SMTP:cylin@sis.com.tw]
> Sent:	Tuesday, March 25, 1997 9:24 PM
> To:	1394ohci-l@austin.ibm.com
> Subject:	
> 
> Hi,
> 
> In OHCI0.92, page 103, last para. said "software must only use
> resCount
> values when the corresponding xferStatus indicates the run bit is set
> to
> one." However, page 15, last para. said "If software clears a 
> ContextControl.run for an isochronous context while the Host
> Controller is
> processing a packet for the context, the Host controller will continue
> to
> receive or transmit the packet and update descriptor status." Since
> the
> updated status will have run=0, the resCount and thus the packet will
> not be valid to SW, then why requires HC to continue receive the
> packet
> and update descriptor status? It seems that SW use the resCount when
> active is set to one is more reasonable.
> 
> Thanks for your time and answer,
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Chien-Yuh Lin
> Design Engineer
> Basic Technology Group
> Silicon Intergrated Systems Corp.
> Tel: 886-3-5774922 x 4326
> Fax: 886-3-5778774
> Email: cylin@sis.com.tw
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	John Nels Fuller
Sent:	Wednesday, March 26, 1997 9:58 AM
To:	'jyshiuan@sis.com.tw'; 1394ohci-l@austin.ibm.com
Subject:	RE: bus reset packet

The bus reset packet will be synthesized when the ARDMA is enabled.  If
more than one bus reset has occurred then only the last one needs to be
placed into the AR context.  This is also true is the ARDMA is enabled
but out of buffers, the bus reset packet will be synthesized when a new
buffer arrives.

Whether or not the bus reset is passed through the AR request FIFO is an
implementation decision.  If the AR request FIFO is combined with the AR
response and/or IR FIFO then most probably a bus reset token will pass
through the FIFO since we don't want to purge valid response or IR
packets from the FIFO at bus reset.  If the AR request FIFO is a
separate FIFO then the bus reset need not pass through the FIFO as the
FIFO can just be cleared by the bus reset.

I hope this helps.
_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> -----Original Message-----
> From:	jyshiuan@sis.com.tw [SMTP:jyshiuan@sis.com.tw]
> Sent:	Wednesday, March 26, 1997 3:54 AM
> To:	1394ohci-l@austin.ibm.com
> Subject:	bus reset packet
> 
> hi all:
> 
>   I have a question about the bus reset packet.
> 
>   according to the OHCI 0.92, 8.4.2.3.
>   it said:"Host controller inserts a synthesized PHY packet into the
> ARDMA.
>   Request context buffer as soon as a bus reset condition is dected."
> 
>   My question is :
>     if a bus reset condition occurs before the time that ARDMA request
> context enables,
>     will the bus reset packet inserts into the ARDMA buffer after the
> ARDMA
> is enabled?
> 
>    because the bus reset packet is used to distinguish the packets
> before or
> after bus reset,
>    I think that the bus reset packet do not have to insert into the
> ARDMA FIFO.
>    Am i correct?
> 
>   Thanks for your time and answer.
> 
> ===============================================
> Jing-Yeh Shiuan
> Engineer
> Basic Technology Group
> Silicon Integrated Systems Corp.
> E-mail:     jyshiuan@sis.comp.tw
> Phone:     886-3-5774922 ext 4302
> Fax:          886-3-5790651
> Email:      jyshiuan@sis.com.tw
> Address: No 16, Creation Rd 1, 
>                  Science-based Industrial Park,
>                  Hsin Chu, Taiwan, R. O. C.
> ==============================================
From:	Sean_Souffie@wlgore.com
Sent:	Wednesday, March 26, 1997 9:46 AM
To:	1394ohci-l@austin.ibm.com
Subject:	unsubscribe





unsubscribe

From:	David Brief [David.Brief@nsc.com]
Sent:	Thursday, March 27, 1997 12:01 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: questions about cycleX events

While we're talking about Cycle events-
 there are a few other items that require some reading
between the lines that we'd like to take the guesswork out of. Here's
our
interpretation and questions.

cycleInconsistent:
	this event should only occur for a non-master.
	this event should not occur when the cycle timer is just starting up
and resynchronizing
	to the cycle_start - for example - after a bus reset, or after
	the LinkControl.cycleTimerEnable bit is set
	

	when a cycle inconsistent event occurs what is supposed to happen to
the
	value in the cycle timer register?
	since this should be a very rare occurence, and certainly indicates an
	error condition (what is the likelihood of getting a cycle start packet
	with the wrong number if the crc is correct?) I think we should 
	just load up the received cycle_time_data into the cycle timer
register.

	A CRC error on the cycle start packet should not cause this event to be
set.
	A CRC error should not prevent transmission of any enqueued iso
packets.


CycleTooLong -
	this can occur when two 1394 segments are joined together and the
isochronous
	allocation overruns a 125 usec cycle. 
	Another event that can be used to potentially detect this condition is 
	Duplicate_channel_detected as defined in 6.1.1.3 of the 1394-1995 spec.
	I'm wondering why this event was not included in OpenHCI. Are you
relying
	on software to detect this based on the time stamp in the iso packets?


CycleLost -
	this is covered by the thread below. additional comments embedded:

DavidW@bangate.compaq.com wrote:
> 
> Responses embedded below.
> 
> David
> 
> mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
> |
> | The cycleLost event on OHCI092, Table 6-1. It states as folllows:
> |
> | [ cycleLost indicates that an expected cycle start has not been received.
> | This will be set whenever a cycle start is not received immediately after
> | the first subaction gap after the cycleSynch event, ot if an arbitration
> | reset gap is detected after a cycleSynch event without an intervening cycle
> | start.]
> 
> A lost cycle is indicated if no cycleStart is sent/received between two
> successive cycleSynch events.  We think that this can be predicted by noticing
> that a cycle_start packet did not occur when it should have.   We should have
> made the definition clearer and then added the examples for when it can be
> predicted.
> 
> |
> | The questions are,
> | 1. when the host controller itself is a cycle master, will it set this
> |    event bit when it "want" to send a cycle start packet but it can't?
> |    Such as in bus reset period ?
> 
> HC will set this if it can't send cycle_start in an cycle.
> 
> |
> | 2. when the cycleLost resulted by the bus reset, this bit will not be
> |    set according to the definition of Table 6-1, because there is no
> |    subaction gap or arbitration reset gap during bus reset period.
> |    For example, when a bus reset period crosses cycle N-1, cycle N, and
> |    cycle N+1, between the two cycle sync. of cycle N and cycle N+1,
> |    no cycle start packet is sent, thus no isochronous cycle between these
> |    two cycle sync..
> |    In the definition of section 9.3.3, I think the above condition
> |    is a truely cycleLost which is conflict with the definition of
> |    Table 6-1. Have I missed anything ?
> 
> No, you have not missed anything.  The rule should be stated as follows:
> 
> "A lost cycle is indicated when no cycle_start packet is sent/received between
> two successive  cycleSynch events.  A lost cycle can be predicted when a
> cycle_start packet does not immediately follow the first subaction gap after a
> cycleSynch event or if an arbitration reset gap is detected after a cycleSynch
> even without an intervening cycle start.  cycleLost may be set either when it
> occurs or when logic predicts that it will occur."
> 

If a crc errors occurs on a cycle start packet - this should still
probably cause 
the lost cycle event bit to be set (even if the packet has the proper
tcode), but 
any enqued iso packets should still be sent out in this cycle. 

Now to split some hairs-
it seems that there is a difference between the cycleLost event as
indicated in the 
IntEvent register and the cycle loss discussed in relation to IT.
what precisely is the definition of a lost cycle as it relates to IT?
just because a cycle_start packet gets corrupted doesn't mean that we
should
penalize all of the isochronous channels to initiate their branching
etc. 
My understanding is that this cycle loss is due to something like a bus
reset
which prevents sending any data.
Just because we lose a cycle start packet doesn't mean that the entire
cycle is lost.


Can anyone spare a few cycles to get me/us out of the weeds?


Thanks,
David Brief
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, March 25, 1997 8:30 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Ack_type_error Condition

For all block requests other than compare_swap of the isochronous resource 
management registers , if the extended tcode is not zero, send ack_pending and 
put the  packet to the AR request unit even if the packet would otherwise be 
handled by the physical unit.  I believe that this is the only way that we can 
define the behavior so that we can use it for something useful in the future.  
I also don't think this adds much as we already need to do a extended tcode 
check for accesses to the isochronous resource management registers.

For requests which access the isochronous resource management registers, only 
tcode 4 (quadlet read request) and tcode 9 (lock request) are allowed.  For 
tcode 9 requests, the extended tcode must be 2 (compare_swap) and the 
data_length must be 8.  If the request does not fit these profiles, then 
either ack_type_error or a resp_type_error should be returned.

David

shuming@sis.com.tw Wrote:
| 
| Hi, all, 
| 
|   I have a question about Ack_type_error condition.
| 
|   OHCI0.92 page 15, it says"ACK_TYPE_ERROR: A field in the request 
| packet header was set to an unsupported or incorrect value, or....."
| 
|   My question is : If the extended_Tcode field of block read/write request 
is 
| not 
| ZERO, shall HC return ACK_TYPE_ERROR? Will this field be used for
| some special purpose in the future?
| 
| Thanks for your time and answers. 
|   
| ***************************************************************
| Shu-Ming Liu                                                 
| Software Engineer                                            
| Software Design Department                                   
| Silicon Integrated Systems Corp.                             
| Phone 886-35-774922 ext 4157                                 
| Fax   886-35-790651                                          
| 
mailto
shuming@sis.com.tw                                  
| ***************************************************************
| 
From:	DavidW@bangate.compaq.com
Sent:	Thursday, March 27, 1997 12:10 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Remind Me re:Swap decision for Physical accesses?

Any access to a location outside of the HC will use noByteSwapData to 
determine if swaping is done.  Accesses which are resolved within the HC are 
done with no byte swaping.

David

Jerry Hauck <Jerry_Hauck@ccm.sc.intel.com> Wrote:
| 
|      Hi all,
|      
|      At out face-to-face meeting last week, I think there was some 
|      discussion and a conclusion about when and if to swap data on physical 
|      requests versus asynch requests (or something like that).
|      
|      Could someone please remind me of the basic issue and the outcome?  My 
|      notes are nonexistent on this point.
|      
|      Thanks,
|      Jerry Hauck
|      Intel Corp.
|      jerry_hauck@ccm.sc.intel.com
|      408-765-5528
| 
From:	John Nels Fuller
Sent:	Thursday, March 27, 1997 1:36 PM
To:	1394ohci-l@austin.ibm.com
Subject:	RE: Remind Me re:Swap decision for Physical accesses?

I feel compelled to clarify that David's statement is the rule for the
Physical DMA.  The rules for the other DMA's are as they have been, if
the access represents 'data' then the noByteSwapData bit is applied.

> -----Original Message-----
> From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
> Sent:	Thursday, March 27, 1997 12:10 PM
> To:	1394ohci-l@austin.ibm.com
> Subject:	re: Remind Me re:Swap decision for Physical accesses?
> 
> Any access to a location outside of the HC will use noByteSwapData to 
> determine if swaping is done.  Accesses which are resolved within the
> HC are 
> done with no byte swaping.
> 
> David
> 
> Jerry Hauck <Jerry_Hauck@ccm.sc.intel.com> Wrote:
> | 
> |      Hi all,
> |      
> |      At out face-to-face meeting last week, I think there was some 
> |      discussion and a conclusion about when and if to swap data on
> physical 
> |      requests versus asynch requests (or something like that).
> |      
> |      Could someone please remind me of the basic issue and the
> outcome?  My 
> |      notes are nonexistent on this point.
> |      
> |      Thanks,
> |      Jerry Hauck
> |      Intel Corp.
> |      jerry_hauck@ccm.sc.intel.com
> |      408-765-5528
> | 
From:	jyshiuan@sis.com.tw
Sent:	Thursday, March 27, 1997 7:20 PM
To:	1394ohci-l@austin.ibm.com
Subject:	SHORT packet in Buffer fill mode

hi all:

  I have a question about IR Buffer Fill mode.

  If we are at the last buffer for the IR and the rescount is 20 bytes.
 But the next receive packet is 30 bytes.

  What is the hardware behavior?

  Will hareware updates the first 20 bytes and clear the active bit 
  and set evt_code to ack_data_err? ( becasue the data length mismatch with
the data)

  Or hardware should backout the receive 30 bytes,
  and keep listening to the next packets?

  Thanks for the answer.

===============================================
Jing-Yeh Shiuan
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
E-mail:     jyshiuan@sis.comp.tw
Phone:     886-3-5774922 ext 4302
Fax:          886-3-5790651
Email:      jyshiuan@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan, R. O. C.
==============================================
From:	rhsheu@sis.com.tw
Sent:	Friday, March 28, 1997 3:44 AM
To:	1394ohci-l@austin.ibm.com
Cc:	jyshiuan@sis.com.tw; rhsheu@sis.com.tw
Subject:	PCI Global Swap Bit

John,

OHCI spec 0.92 section B.4: 
"PCI Global Swap Bit ----- When this bit is b'1, all quadlets read from and
written to the PCI interface are byte swapped. PCI addresses, such as
expansion ROM and PCI config registers, are unaffected by this bit (they are
not byte swapped under any circumstances)."

Could you specify "PCI addresses" more explicit ?

When PCI Global Swap Bit is set to '1':  
1. If the OHCI Host Controller issues a PCI master cycle to the PCI bus,
data & byte enable MUST be swapped whatever the cycle is read or write.
2. If a PCI target cycle is claimed by the OHCI Host Controller, data & byte
enable WON'T be swapped whatever the cycle is read or write, and whatever
the access target is Expansion ROM, PCI configure register or Open HCI register.

Could you give some comment on the above description?

Thanks!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ruey-Horng Sheu
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 432e
Fax: 886-3-5778774
Email: rhsheu@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	John Nels Fuller
Sent:	Friday, March 28, 1997 10:34 AM
To:	'rhsheu@sis.com.tw'; 1394ohci-l@austin.ibm.com
Cc:	jyshiuan@sis.com.tw
Subject:	RE: PCI Global Swap Bit

"PCI addresses" refers to the PCI Configuration Space as defined in the
PCI spec.

I hope someone else can comment on the description, because it's not
making sense to me.

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> -----Original Message-----
> From:	rhsheu@sis.com.tw [SMTP:rhsheu@sis.com.tw]
> Sent:	Friday, March 28, 1997 3:44 AM
> To:	1394ohci-l@austin.ibm.com
> Cc:	jyshiuan@sis.com.tw; rhsheu@sis.com.tw
> Subject:	PCI Global Swap Bit
> 
> John,
> 
> OHCI spec 0.92 section B.4: 
> "PCI Global Swap Bit ----- When this bit is b'1, all quadlets read
> from and
> written to the PCI interface are byte swapped. PCI addresses, such as
> expansion ROM and PCI config registers, are unaffected by this bit
> (they are
> not byte swapped under any circumstances)."
> 
> Could you specify "PCI addresses" more explicit ?
> 
> When PCI Global Swap Bit is set to '1':  
> 1. If the OHCI Host Controller issues a PCI master cycle to the PCI
> bus,
> data & byte enable MUST be swapped whatever the cycle is read or
> write.
> 2. If a PCI target cycle is claimed by the OHCI Host Controller, data
> & byte
> enable WON'T be swapped whatever the cycle is read or write, and
> whatever
> the access target is Expansion ROM, PCI configure register or Open HCI
> register.
> 
> Could you give some comment on the above description?
> 
> Thanks!
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Ruey-Horng Sheu
> Design Engineer
> Basic Technology Group
> Silicon Intergrated Systems Corp.
> Tel: 886-3-5774922 x 432e
> Fax: 886-3-5778774
> Email: rhsheu@sis.com.tw
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	daisy@sis.com.tw
Sent:	Sunday, March 30, 1997 10:45 PM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw
Subject:	overrun condition and selfID Unit

Hi, all,

I have some questions about OHCI v0.92, I appreciate if anyone can 
clearify them.

1. Suppose the Receive FIFO is full when a packet is comming from LINK, and no
any hearer/data of the packet can be put into the FIFO, then in the DMA side,
it behaves as if the packet never comes in, am I right ?

2.1 If the above statement is right, I'm wondering if the selfID Unit can
do the same thing when receiving selfID packets.
If no selfID packets in the RxFIFO due to the overrun condtion, I think 
the selfID unit will not set selfIDError, not increase the selfIDGeneration
count, and not set the selfIDcomplete bit in IntEvent, thus causes
no selfID interrupt after a bus reset event. Will this cause any problem
to software ?

2.2 If the statement is wrong, should selfID unit set the selfIDError and
increase the selfIDGeneration ?

3. If there is no selfIDcomplete interrupt after the bus reset event, 
I think the contents of the selfID Count registers are meaningless to 
sofeware, right ?

4. The spec says the selfID unit increase the selfIDGerenation count 
each time "the self ID reception process" begin. If the statement in 1. is 
right, I think the selfID reception process means the process of writting 
selfID packets to memory, so, if there is no selfID packets can be written
to memory, the selfIDGerenation count will not be increased, am I right ?
Will software use the selfIDGeneration to know how many times the
selfID recetion occurs, or just use this value to check if the contents in 
the selfID buffer is valid ?  


Regards,

Y.J. Chao
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================
From:	DavidW@bangate.compaq.com
Sent:	Monday, March 31, 1997 7:00 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: SHORT packet in Buffer fill mode

The last packet gets backed out and the context stays active.

David


jyshiuan@sis.com.tw (jyshiuan) Wrote:
| 
| hi all:
| 
|   I have a question about IR Buffer Fill mode.
| 
|   If we are at the last buffer for the IR and the rescount is 20 bytes.
|  But the next receive packet is 30 bytes.
| 
|   What is the hardware behavior?
| 
|   Will hareware updates the first 20 bytes and clear the active bit 
|   and set evt_code to ack_data_err? ( becasue the data length mismatch with
| the data)
| 
|   Or hardware should backout the receive 30 bytes,
|   and keep listening to the next packets?
| 
|   Thanks for the answer.
| 
| ===============================================
| Jing-Yeh Shiuan
| Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.
| E-mail:     jyshiuan@sis.comp.tw
| Phone:     886-3-5774922 ext 4302
| Fax:          886-3-5790651
| Email:      jyshiuan@sis.com.tw
| Address: No 16, Creation Rd 1, 
|                  Science-based Industrial Park,
|                  Hsin Chu, Taiwan, R. O. C.
| ==============================================
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Monday, March 31, 1997 7:13 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: PCI Global Swap Bit

As per John's request, responses embedded below.

David

rhsheu@sis.com.tw (Ruey-Horng Sheu) Wrote:
| 
| John,
| 
| OHCI spec 0.92 section B.4: 
| "PCI Global Swap Bit ----- When this bit is b'1, all quadlets read from and
| written to the PCI interface are byte swapped. PCI addresses, such as
| expansion ROM and PCI config registers, are unaffected by this bit (they are
| not byte swapped under any circumstances)."
| 
| Could you specify "PCI addresses" more explicit ?
| 
| When PCI Global Swap Bit is set to '1':  
| 1. If the OHCI Host Controller issues a PCI master cycle to the PCI bus,
| data & byte enable MUST be swapped whatever the cycle is read or write.

If OHCI initiates a PCI cycle, if PCI Global Swap bit is set, it will swap 
data bytes and byte enables for writes and will swap data bytes for reads. 

| 2. If a PCI target cycle is claimed by the OHCI Host Controller, data & byte
| enable WON'T be swapped whatever the cycle is read or write, and whatever
| the access target is Expansion ROM, PCI configure register or Open HCI 
register.

Reads or writes of OHCI registers are byte swapped if PCI Global Swap bit set. 
 For writes, only quadlet writes are efined so byte enables should be don't 
care.

Reads or writes of PCI configuration space are not byte swapped.

Reads of Expansion ROM is not defined but since the ROM space is not part of 
the 2K bytes of OHCI register space, I would think that they would _NOT_ be 
byte swapped.

| 
| Could you give some comment on the above description?
| 
| Thanks!
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Ruey-Horng Sheu
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 432e
| Fax: 886-3-5778774
| Email: rhsheu@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	David Brief [David.Brief@nsc.com]
Sent:	Tuesday, April 01, 1997 9:57 AM
To:	1394ohci-l@austin.ibm.com
Subject:	questions about cycleX events

I sent the following message out last week and didn't get any reactions.
I thought I'd try again.

thanks,
David Brief


       Subject: 
                 Re: questions about cycleX events
          Date: 
                 Thu, 27 Mar 1997 11:00:32 +0300
         From: 
                 David Brief <David.Brief@nsc.com>
Organization: 
                 Advance Development 
             To: 
                 1394ohci-l@austin.ibm.com
   References: 
                 1


While we're talking about Cycle events-
 there are a few other items that require some reading
between the lines that we'd like to take the guesswork out of. Here's
our
interpretation and questions.

cycleInconsistent:
        this event should only occur for a non-master.
        this event should not occur when the cycle timer is just
starting up
and resynchronizing
        to the cycle_start - for example - after a bus reset, or after
        the LinkControl.cycleTimerEnable bit is set
        

        when a cycle inconsistent event occurs what is supposed to
happen to
the
        value in the cycle timer register?
        since this should be a very rare occurence, and certainly
indicates an
        error condition (what is the likelihood of getting a cycle start
packet
        with the wrong number if the crc is correct?) I think we should 
        just load up the received cycle_time_data into the cycle timer
register.

        A CRC error on the cycle start packet should not cause this
event to be
set.
        A CRC error should not prevent transmission of any enqueued iso
packets.


CycleTooLong -
        this can occur when two 1394 segments are joined together and
the
isochronous
        allocation overruns a 125 usec cycle. 
        Another event that can be used to potentially detect this
condition is 
        Duplicate_channel_detected as defined in 6.1.1.3 of the
1394-1995 spec.
        I'm wondering why this event was not included in OpenHCI. Are
you
relying
        on software to detect this based on the time stamp in the iso
packets?


CycleLost -
        this is covered by the thread below. additional comments
embedded:

DavidW@bangate.compaq.com wrote:
> 
> Responses embedded below.
> 
> David
> 
> mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
> |
> | The cycleLost event on OHCI092, Table 6-1. It states as folllows:
> |
> | [ cycleLost indicates that an expected cycle start has not been received.
> | This will be set whenever a cycle start is not received immediately after
> | the first subaction gap after the cycleSynch event, ot if an arbitration
> | reset gap is detected after a cycleSynch event without an intervening cycle
> | start.]
> 
> A lost cycle is indicated if no cycleStart is sent/received between two
> successive cycleSynch events.  We think that this can be predicted by noticing
> that a cycle_start packet did not occur when it should have.   We should have
> made the definition clearer and then added the examples for when it can be
> predicted.
> 
> |
> | The questions are,
> | 1. when the host controller itself is a cycle master, will it set this
> |    event bit when it "want" to send a cycle start packet but it can't?
> |    Such as in bus reset period ?
> 
> HC will set this if it can't send cycle_start in an cycle.
> 
> |
> | 2. when the cycleLost resulted by the bus reset, this bit will not be
> |    set according to the definition of Table 6-1, because there is no
> |    subaction gap or arbitration reset gap during bus reset period.
> |    For example, when a bus reset period crosses cycle N-1, cycle N, and
> |    cycle N+1, between the two cycle sync. of cycle N and cycle N+1,
> |    no cycle start packet is sent, thus no isochronous cycle between these
> |    two cycle sync..
> |    In the definition of section 9.3.3, I think the above condition
> |    is a truely cycleLost which is conflict with the definition of
> |    Table 6-1. Have I missed anything ?
> 
> No, you have not missed anything.  The rule should be stated as follows:
> 
> "A lost cycle is indicated when no cycle_start packet is sent/received between
> two successive  cycleSynch events.  A lost cycle can be predicted when a
> cycle_start packet does not immediately follow the first subaction gap after a
> cycleSynch event or if an arbitration reset gap is detected after a cycleSynch
> even without an intervening cycle start.  cycleLost may be set either when it
> occurs or when logic predicts that it will occur."
> 

If a crc errors occurs on a cycle start packet - this should still
probably cause 
the lost cycle event bit to be set (even if the packet has the proper
tcode), but 
any enqued iso packets should still be sent out in this cycle. 

Now to split some hairs-
it seems that there is a difference between the cycleLost event as
indicated in the 
IntEvent register and the cycle loss discussed in relation to IT.
what precisely is the definition of a lost cycle as it relates to IT?
just because a cycle_start packet gets corrupted doesn't mean that we
should
penalize all of the isochronous channels to initiate their branching
etc. 
My understanding is that this cycle loss is due to something like a bus
reset
which prevents sending any data.
Just because we lose a cycle start packet doesn't mean that the entire
cycle is lost.


Can anyone spare a few cycles to get me/us out of the weeds?


Thanks,
David Brief
From:	DavidW@bangate.compaq.com
Sent:	Monday, March 31, 1997 8:21 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: overrun condition and selfID Unit

Responses embedded below.

David


daisy@sis.com.tw (Yen-Jiuan Chao) Wrote:
| 
| Hi, all,
| 
| I have some questions about OHCI v0.92, I appreciate if anyone can 
| clearify them.
| 
| 1. Suppose the Receive FIFO is full when a packet is comming from LINK, and 
no
| any hearer/data of the packet can be put into the FIFO, then in the DMA 
side,
| it behaves as if the packet never comes in, am I right ?

DMA side should not 'see' the packet.  If there was no room in the receive 
FIFO, the link side should drop the entire packet and, unless the packet was a 
PHY, iso or broadcast, send an ack_busy.

| 
| 2.1 If the above statement is right, I'm wondering if the selfID Unit can
| do the same thing when receiving selfID packets.
| If no selfID packets in the RxFIFO due to the overrun condtion, I think 
| the selfID unit will not set selfIDError, not increase the selfIDGeneration
| count, and not set the selfIDcomplete bit in IntEvent, thus causes
| no selfID interrupt after a bus reset event. Will this cause any problem
| to software ?

SelfIDGeneration value in Self ID Count register must increase after each bus 
reset (or at the start of each selfID phase of the 1394 bus.)  The fact that 
the receive buffer is full when the reset occurs can't prevent selfID count 
from incrementing.

| 
| 2.2 If the statement is wrong, should selfID unit set the selfIDError and
| increase the selfIDGeneration ?

Loss of selfID packets should be detected by link side and cause selfIDError 
to be set.

| 
| 3. If there is no selfIDcomplete interrupt after the bus reset event, 
| I think the contents of the selfID Count registers are meaningless to 
| sofeware, right ?

Yes, sort of.  I think the next release will have more details on this.

| 
| 4. The spec says the selfID unit increase the selfIDGerenation count 
| each time "the self ID reception process" begin. If the statement in 1. is 
| right, I think the selfID reception process means the process of writting 
| selfID packets to memory, so, if there is no selfID packets can be written
| to memory, the selfIDGerenation count will not be increased, am I right ?
| Will software use the selfIDGeneration to know how many times the
| selfID recetion occurs, or just use this value to check if the contents in 
| the selfID buffer is valid ?  

SelfID reception process begins when selfID packets start ariving at HC link.  
It is _not_ tied to writing data to memory. 

| 
| 
| Regards,
| 
| Y.J. Chao
| ====================================
| Yen-Jiuan Chao (Daisy)
| Design Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.(SiS)
| Phone  : 886-3-5774922 ext. 4315
| Fax    : 886-3-5790651
| E-mail : daisy@sis.com.tw
| =====================================
| 
| 
From:	PJohansson@aol.com
Sent:	Thursday, April 03, 1997 12:18 PM
To:	p1394@sun.com
Cc:	1394-architecture@1394ta.org; 1394ohci-l@austin.ibm.com
Subject:	"Fairness" and 1394 Asynchronous Arbitration

A document, 97-015r0.pdf, has just been posted to the P1394a FTP site,
ftp://ftp.symbios.com:/pub/standards/io/1394/P1394a, that proposes a change
in 1394-1995 to permit nodes to arbitrate for asynchronous request packets
more than once in a single fairness interval. Present day 1394-1995 restricts
a node to a single bus arbitration for any kind of asynchronous primary
packet during a fairness interval.

Because this topic is still being debated, I thought it best to summarize the
technical details and make them available in a separate document.

A vote on this proposal (or a modified version) will be scheduled for the
Phoenix meeting, May 20 - 21, 1997.

I've copied the OpenHCI reflector on this announcement because there may be
implications for OpenHCI implementations.

When you visit the FTP site, check out the new directory structure and a
Document Index that provides a quick reference to all of the documents now
available at the site.

Regards,

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com
From:	okazaki@cpl.toshiba.co.jp
Sent:	Thursday, April 03, 1997 5:52 PM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

Dear administrator,

 Please add me to the 1394 Open HCI reflector.
If this is a wrong way to subscribe,please let me know
a right way.

Thank you in advance.

 Jun Okazaki
 Toshiba Multimedia Engineering LAB.
E-mail: okazaki@cpl.toshiba.co.jp
Phone: +81-45-770-3325
Fax  : +81-45-770-3191

From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Sunday, April 06, 1997 5:38 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[2]: questions about cycleX events

David (Brief),

I can't answer all of your questions, but some comments are embedded below.

Regards,
Jerry Hauck
Intel Corp.
(408) 765-5528


> While we're talking about Cycle events-
>  there are a few other items that require some reading
> between the lines that we'd like to take the guesswork out of. Here's 
> our
> interpretation and questions.
>   
> cycleInconsistent:
>      this event should only occur for a non-master.
>      this event should not occur when the cycle timer is just starting up
> and resynchronizing
>      to the cycle_start - for example - after a bus reset, or after 
>      the LinkControl.cycleTimerEnable bit is set

Actually, I believe that cycleInconsistent can and should happen after a bus 
reset if a cycle start is received which is inconsistent with the cycleSeconds 
and cycleCount fields of the cycle timer register.  This is particularly 
important after two 1394 buses (with separate IRM's and cycle counts) are 
joined.  After the ensuing bus reset, only one IRM remains.  OHCI devices which 
were part of the "losing" IRM bus and were configured to perform cycleMatch 
processing now have an issue: the cycle count they are waiting for may never 
come or won't come for a very long time.  The cycleInconsistent event notifies 
software that isochronous contexts relying on cycleMatch must now be 
resynchronized to the new cycle time.  I believe the details of this process 
will be documented in the next release of the OHCI spec.

>   
>   
>      when a cycle inconsistent event occurs what is supposed to happen to
> the
>      value in the cycle timer register?
>      since this should be a very rare occurence, and certainly indicates an 
>      error condition (what is the likelihood of getting a cycle start packet 
>      with the wrong number if the crc is correct?) I think we should
>      just load up the received cycle_time_data into the cycle timer
> register.
>   
>      A CRC error on the cycle start packet should not cause this event to be
> set.
>      A CRC error should not prevent transmission of any enqueued iso
> packets.
>   

I'm not sure I understand your intention with the above statements.  The cycle 
start packet has a single header CRC.  If this CRC contains an error, I believe 
by 1394-1995 rules you MUST ignore the packet ... it never happened.  You 
can't/shouldn't look at the tcode and assume that it was a cycle start.  Since 
you never received this errant cycle start, the cycleInconsistent event won't be
set and you must not start sending isochronous packets until an error-free cycle
start is received.

>   
> CycleTooLong -
>      this can occur when two 1394 segments are joined together and the
> isochronous
>      allocation overruns a 125 usec cycle.
>      Another event that can be used to potentially detect this condition is 
>      Duplicate_channel_detected as defined in 6.1.1.3 of the 1394-1995 spec. 
>      I'm wondering why this event was not included in OpenHCI. Are you
> relying
>      on software to detect this based on the time stamp in the iso packets?
>   
>   
> CycleLost -
>      this is covered by the thread below. additional comments embedded:
>   
> DavidW@bangate.compaq.com wrote:
> >
> > Responses embedded below.
> >
> > David
> >
> > mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote: 
> > |
> > | The cycleLost event on OHCI092, Table 6-1. It states as folllows: 
> > |
> > | [ cycleLost indicates that an expected cycle start has not been received. 
> > | This will be set whenever a cycle start is not received immediately after 
> > | the first subaction gap after the cycleSynch event, ot if an arbitration
> > | reset gap is detected after a cycleSynch event without an intervening 
cycle 
> > | start.]
> >
> > A lost cycle is indicated if no cycleStart is sent/received between two 
> > successive cycleSynch events.  We think that this can be predicted
> by noticing
> > that a cycle_start packet did not occur when it should have.   We should 
have 
> > made the definition clearer and then added the examples for when it can be
> > predicted.
> >
> > |
> > | The questions are,
> > | 1. when the host controller itself is a cycle master, will it set this 
> > |    event bit when it "want" to send a cycle start packet but it can't? 
> > |    Such as in bus reset period ?
> >
> > HC will set this if it can't send cycle_start in an cycle. 
> >
> > |
> > | 2. when the cycleLost resulted by the bus reset, this bit will not be 
> > |    set according to the definition of Table 6-1, because there is no 
> > |    subaction gap or arbitration reset gap during bus reset period.
> > |    For example, when a bus reset period crosses cycle N-1, cycle N, and 
> > |    cycle N+1, between the two cycle sync. of cycle N and cycle N+1,
> > |    no cycle start packet is sent, thus no isochronous cycle between these 
> > |    two cycle sync..
> > |    In the definition of section 9.3.3, I think the above condition 
> > |    is a truely cycleLost which is conflict with the definition of 
> > |    Table 6-1. Have I missed anything ?
> >
> > No, you have not missed anything.  The rule should be stated as follows: 
> >
> > "A lost cycle is indicated when no cycle_start packet is sent/received 
> between
> > two successive  cycleSynch events.  A lost cycle can be predicted when a 
> > cycle_start packet does not immediately follow the first subaction
> gap after a
> > cycleSynch event or if an arbitration reset gap is detected after 
> a cycleSynch
> > even without an intervening cycle start.  cycleLost may be set either when 
it 
> > occurs or when logic predicts that it will occur."
> >
>   
> If a crc errors occurs on a cycle start packet - this should still 
> probably cause
> the lost cycle event bit to be set (even if the packet has the proper 
> tcode), but
> any enqued iso packets should still be sent out in this cycle.

Again, I may be confused.  But a header CRC error on any packet causes that 
packet to be discarded and ignored.  So, in the case above, a lost cycle would 
be detected if a valid error-free cycle start packet is not detected according 
to the statements David Wooten makes above.  Queued isochronous packets can NOT 
be sent out in any cycle until an error free cycle start is received.

>   
> Now to split some hairs-
> it seems that there is a difference between the cycleLost event as 
> indicated in the
> IntEvent register and the cycle loss discussed in relation to IT. 
> what precisely is the definition of a lost cycle as it relates to IT? 
> just because a cycle_start packet gets corrupted doesn't mean that we 
> should
> penalize all of the isochronous channels to initiate their branching 
> etc.
> My understanding is that this cycle loss is due to something like a bus 
> reset
> which prevents sending any data.
> Just because we lose a cycle start packet doesn't mean that the entire 
> cycle is lost.
>   

If a cycle start packet is "lost", whether due to corruption or an interfering 
bus reset, isochronous packets will not be transmitted until the next cycle 
start is received.  Consequently, losing a cycle start packet does in fact mean 
"that the entire cycle is lost" and the IT contexts must perform skip processing
to catch up.

In my thinking, there is one additional "cycle loss" case which applies to IT.  
If the isochronous period is interrupted due to any condition which allows a 
subaction gap to occur before all isochronous packets for a cycle have been 
sent, then a cycle has been "lost" and the IT must begin skip processing on the 
next "convenient" cycle boundary.  Note that this can occur even if the cycle 
start packet was properly received.  (A bus reset after the cycle start can 
cause this, for example.)

Whether this condition should trigger the cycleLost event as well is a good 
question for which I don't have the answer.

>   
> Can anyone spare a few cycles to get me/us out of the weeds?
>   
>   
> Thanks,
> David Brief
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Wednesday, April 09, 1997 10:08 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Multi-channel IR context


Text item: 


On page 110, section 10.4.3, last paragraph, OHCI states that if a channel is 
programmed for both the multi-channel and single-channel contexts, that the data
is sent to the multi-channel context.  Should the single channel context remain 
active, but with no data going to it?  Or should we kill the single channel 
context?  Or, better yet, do we care?

Joe

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

X-Mailer: Pegasus Mail for Win32 (v2.41)
Priority: normal
Subject: Ack_type_error Condition
Date: Tue, 25 Mar 1997 17:40:37 +0000
To: 1394ohci-l@austin.ibm.com
Comments: Authenticated sender is <shuming@axp.sis.com.tw>
Message-Id: <9703250941.AA11623@axp.sis.com.tw>
Received: from [192.9.209.141] by axp.sis.com.tw; (5.65/1.1.8.2/03Jun96-0539PM)
     id AA11623; Tue, 25 Mar 1997 17:41:05 +0800
Received: from axp.sis.com.tw by sismg.sis.com.tw; (5.65v3.2/1.1.8.2/06Jan96-122
0PM)
     id AA10412; Tue, 25 Mar 1997 17:36:44 +0800
From: shuming@sis.com.tw
Received: from sisfw1.sis.com.tw ([203.67.208.1]) by netmail.austin.ibm.com (8.6
.12/8.6.11) with SMTP id DAA61962 for <1394ohci-l@austin.ibm.com>; Tue, 25 Mar 1
997 03:37:29 -0600
Received: from netmail.austin.ibm.com by calliope.fm.intel.com (8.8.4/10.0i); Tu
e, 25 Mar 1997 09:51:24 GMT
Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) by
fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id CAA15305; Tue, 25 Mar 1997 02:12
:12 -0800 (PST)
Return-Path: leew@austin.ibm.com
From:	yehiel engel [YENGEL@HAIFASC3.HAIFA.IBM.COM]
Sent:	Wednesday, April 09, 1997 10:43 AM
To:	1394ohci-l@austin.ibm.com
Cc:	PELED@HAIFASC3.HAIFA.IBM.COM; YENGEL@HAIFASC3.HAIFA.IBM.COM
Subject:	More questions

=======================

Hello all.
I have two questions concerning the IR interrupts
mechanism.
1. In buffer fill mode the if the field value is 2'b11 then
   an interrupt is generated when the descriptor is completed.
   I wish to know if we should generate the interrupt when the
   buffer is completed, or when the packet that fill the buffer
   was written to the memory without any data errors.
   If the first assumption is true, then the software should have
   recovery mechanism for packets that will have data errors and
   will be "Backout" later. In such case there might be some wrong interrupts
   (one for each buffer).This buffers later will be free again and no
   status will be updated for them.
2. In packet per buffer mode i think that the interrupt field should be set
   only for one descriptor (e.g INPUT_LAST descriptor). I do not see any
   reason to give more then interrupt per packet.

Any comments will be appreciated.

Regards
Yehiel Engel
From:	Diana.Klashman@East.Sun.COM
Sent:	Wednesday, April 09, 1997 7:43 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: More questions

>From YENGEL@HAIFASC3.HAIFA.IBM.COM Wed Apr  9 14:03:49 1997
>
>Hello all.
>I have two questions concerning the IR interrupts
>mechanism.
>1. In buffer fill mode the if the field value is 2'b11 then
>   an interrupt is generated when the descriptor is completed.
>   I wish to know if we should generate the interrupt when the
>   buffer is completed, or when the packet that fill the buffer
>   was written to the memory without any data errors.
>   If the first assumption is true, then the software should have
>   recovery mechanism for packets that will have data errors and
>   will be "Backout" later. In such case there might be some wrong interrupts
>   (one for each buffer).This buffers later will be free again and no
>   status will be updated for them.

Your second assumption is true.  The descriptor is considered completed
when resCount hits 0.  Since resCount for the descriptor containing
the first fragment of the packet is updated _after_ the resCount/XferStatus
of the descriptor containing the last fragment of the packet, then
you don't run into the problems you describe (since a packet with
an error can be seamlessly backed-out).

I'll see if I can clarify this in step 3 of 10.2.1.


>2. In packet per buffer mode i think that the interrupt field should be set
>   only for one descriptor (e.g INPUT_LAST descriptor). I do not see any
>   reason to give more then interrupt per packet.
>

True.  I'll clarify the "i" description in table 10-1 to say that it 
is ignored for INPUT_MORE in packet-per-buffer mode.

Diana


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From:	shchuang@sis.com.tw
Sent:	Wednesday, April 09, 1997 8:38 PM
To:	1394ohci-l@austin.ibm.com
Subject:	question about destination offset

Hi,


I have a question about destination offset.  In 1394-1995 spec, section
6.2.4.2.2, it states that for the read request for data quadlet and the
write request for data quadlet packets, the destination_offset value shall
be a quadlet aligned address.  If a quadlet read request or a quadlet write
request for the physical memory but the destination_offset value is not a
quadlet aligned address, what should the physical request unit do?

Thanks for your time and answer,




Shiuh-Herng Chuang
From:	David Brief [David.Brief@nsc.com]
Sent:	Thursday, April 10, 1997 4:46 AM
To:	Joseph A Bennett
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: Multi-channel IR context

Joseph A Bennett wrote:
> 
> Text item:
> 
> On page 110, section 10.4.3, last paragraph, OHCI states that if a channel is
> programmed for both the multi-channel and single-channel contexts, that the data
> is sent to the multi-channel context.  Should the single channel context remain
> active, but with no data going to it?  Or should we kill the single channel
> context?  Or, better yet, do we care?
> 
> Joe
> 

Don't kill that context- they both could be active in the period where
you
are moving a channel to or from the multi-channel context. 

-David Brief
From:	jyshiuan@sis.com.tw
Sent:	Friday, April 11, 1997 2:05 AM
To:	1394ohci-l@austin.ibm.com
Subject:	xferStatus update in zero length iso packet

Hi,all:

In OHCI v0.92,page 102, the description about xferStatus in Table 10-1. It
describes that "For buffer fill mode,xferStatus is written when resCount is 
updated." Thus, if a zero length iso packet is received and the packet 
header is stripped off. In this case the xferStatus need not to updated. Is 
this statement right?
Thanks for your time and answer.


===============================================
Jing-Yeh Shiuan
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
E-mail:     jyshiuan@sis.comp.tw
Phone:     886-3-5774922 ext 4302
Fax:          886-3-5790651
Email:      jyshiuan@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan, R. O. C.
==============================================
From:	DavidW@bangate.compaq.com
Sent:	Friday, April 11, 1997 8:50 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Multi-channel IR context

Is it better that we care or better that we don't care?  We do care.  
Single-channel context remains active.  It might be possible to move a channel 
from the multi to a single channel context by setting up the single channel 
context and then simply turing off the channel number in the multi-mode 
register.  This might not be terribly popular thing for SW to do but given 
that this is probably the least hardware intensive solution, let's not leave 
it undefined.

David

Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
| 
| 
| Text item: 
| 
| 
| On page 110, section 10.4.3, last paragraph, OHCI states that if a channel 
is 
| programmed for both the multi-channel and single-channel contexts, that the 
data
| is sent to the multi-channel context.  Should the single channel context 
remain 
| active, but with no data going to it?  Or should we kill the single channel 
| context?  Or, better yet, do we care?
| 
| Joe
| 
| Text item: External Message Header
| 
| The following mail header is for administrative use
| and may be ignored unless there are problems.
| 
| ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
| 
| X-Mailer: Pegasus Mail for Win32 (v2.41)
| Priority: normal
| Subject: Ack_type_error Condition
| Date: Tue, 25 Mar 1997 17:40:37 +0000
| To: 1394ohci-l@austin.ibm.com
| Comments: Authenticated sender is <shuming@axp.sis.com.tw>
| Message-Id: <9703250941.AA11623@axp.sis.com.tw>
| Received: from [192.9.209.141] by axp.sis.com.tw; 
(5.65/1.1.8.2/03Jun96-0539PM)
|      id AA11623; Tue, 25 Mar 1997 17:41:05 +0800
| Received: from axp.sis.com.tw by sismg.sis.com.tw; 
(5.65v3.2/1.1.8.2/06Jan96-122
| 0PM)
|      id AA10412; Tue, 25 Mar 1997 17:36:44 +0800
| From: shuming@sis.com.tw
| Received: from sisfw1.sis.com.tw ([203.67.208.1]) by netmail.austin.ibm.com 
(8.6
| ..12/8.6.11) with SMTP id DAA61962 for <1394ohci-l@austin.ibm.com>; Tue, 25 
Mar 
| 1
| 997 03:37:29 -0600
| Received: from netmail.austin.ibm.com by calliope.fm.intel.com 
(8.8.4/10.0i); Tu
| e, 25 Mar 1997 09:51:24 GMT
| Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) 
by
| fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id CAA15305; Tue, 25 Mar 1997 
02:12
| :12 -0800 (PST)
| Return-Path: leew@austin.ibm.com
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, April 11, 1997 9:21 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: question about destination offset

Send ack_type_err or send resp_type_err or send/receive data that is on 
quadlet boundary.

David



shchuang@sis.com.tw (Shiuh-Herng Chuang) Wrote:
| 
| Hi,
| 
| 
| I have a question about destination offset.  In 1394-1995 spec, section
| 6.2.4.2.2, it states that for the read request for data quadlet and the
| write request for data quadlet packets, the destination_offset value shall
| be a quadlet aligned address.  If a quadlet read request or a quadlet write
| request for the physical memory but the destination_offset value is not a
| quadlet aligned address, what should the physical request unit do?
| 
| Thanks for your time and answer,
| 
| 
| 
| 
| Shiuh-Herng Chuang
| 
| 
From:	SirkinEric@aol.com
Sent:	Sunday, April 13, 1997 5:37 PM
To:	1394ohci-l@austin.ibm.com
Cc:	SirkinEric@aol.com
Subject:	subscribe

 
From:	cylin@sis.com.tw
Sent:	Sunday, April 13, 1997 9:10 PM
To:	1394ohci-l@austin.ibm.com
Subject:	run clear interrupt

Hi,

I have a question about the interrupt issued for run clear:
OHCI0.92, Sec.3.1.1.3, 2nd para., said "When ContextControl.active is 
cleared and ContextControl.run is already clear, the Host Controller will
set the IntEvent bit for the context". My question is, if active is
cleared for some other reasons before run is cleared, does SW exepect
this interrupt?

Thanks for your time and answers,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	David Brief [David.Brief@nsc.com]
Sent:	Monday, April 14, 1997 3:22 AM
To:	Jerry Hauck
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: questions about cycleX events

The 0.93 version cleared up some of the following issues, but
a few remain.


Jerry Hauck wrote:
> >
> > cycleInconsistent:
> >      this event should only occur for a non-master.
> >      this event should not occur when the cycle timer is just starting up
> > and resynchronizing
> >      to the cycle_start - for example - after a bus reset, or after
> >      the LinkControl.cycleTimerEnable bit is set 
> 
> Actually, I believe that cycleInconsistent can and should happen after a bus
> reset if a cycle start is received which is inconsistent with the cycleSeconds
> and cycleCount fields of the cycle timer register.  This is particularly
> important after two 1394 buses (with separate IRM's and cycle counts) are
> joined.  After the ensuing bus reset, only one IRM remains.  OHCI devices which
> were part of the "losing" IRM bus and were configured to perform cycleMatch
> processing now have an issue: the cycle count they are waiting for may never
> come or won't come for a very long time.  The cycleInconsistent event notifies
> software that isochronous contexts relying on cycleMatch must now be
> resynchronized to the new cycle time.  I believe the details of this process
> will be documented in the next release of the OHCI spec.

Yes- this seems reasonable and the 0.93 spec clears up how to handle
this. 
Software should expect to receive the cycleInconsistent event also after
the  LinkControl.cycleTimerEnable bit is set. 
> 
> >
> >
> >      when a cycle inconsistent event occurs what is supposed to happen to
> > the
> >      value in the cycle timer register?
 
In this case it seems that  we should  loadthe received cycle_time_data
into the cycle timer
register. The  extra new requirement that cycle match processing when
this occurs
handles the error cases fine.



cycleLost:

 
In 0.93 the cycleLost definition was updated according to Dave Wooten's
suggestion-

> > > "A lost cycle is indicated when no cycle_start packet is sent/received between
> > > two successive  cycleSynch events.  A lost cycle can be predicted when a
> > > cycle_start packet does not immediately follow the first subaction gap after a
> > > cycleSynch event or if an arbitration reset gap is detected after a cycleSynch
> > > even without an intervening cycle start.  cycleLost may be set either when it
> > > occurs or when logic predicts that it will occur."

 
 Peter Johannson subsequently suggested the following text:
>  
>  "A lost cycle can be detected if a subaction gap is observed after a
>  cycleSynch event without the observation of an intervening cycle start
>  packet"

I  think we have some more work to do on this.

What is the relationship between IT skip processing and this cycle lost
event?
  i.e. is skip processing invoked only after this bit is set?
     are there cases when this bit is set and skip processing does not
occur?
     are there cases when this bit is not set but skip processing does
occur?
 
As a matter of principle, I'd like to see that this cycleLost bit is set
whenever
the skip processing is invoked.   

Then we get into the details of describing exactly when the skip
processing is invoked.

so far I've heard the following cases mentioned:
  1) a valid crc clean cycle_start packet was not received as the next
packet after
    a cycle_sync event.
      - for this case I think it is sufficient to detect a packet with 
        a TCODE that is not 'h8 - the cycle_start tcode.
  2) a cycle_start packet could not be sent after a cycle_sync event (if
this is the master)
        - possibly because of a bus reset
  3) detection of a subaction gap before all iso contexts with data for
this cycle
         have been serviced (i.e. a reset before  iso tx before the
subaction gap)

there may be other cases as well that are implementation dependent- 
but I think that at least these cases should be covered by the
specification.


On another topic:
I'm wondering why the Duplicate_channel_detected event as defined in
 6.1.1.3 of the 1394-1995 spec.was not included in OpenHCI?
Is OpenHCI relying  on software to detect this based on the time stamp
in the iso packets?
 
Regards,
David Brief
From:	Diana.Klashman@East.Sun.COM
Sent:	Monday, April 14, 1997 7:44 AM
To:	1394ohci-l@austin.ibm.com
Subject:	OpenHCI 0.93

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 19

1394 OpenHCI version 0.93 will be available on the
1394 OpenHCI ftp site in a few days.

In the meantime, you can obtain a copy from 

ftp://ftp.sun.com/pub/1394/ohci093.pdf


Attached to this email is the editor's checklist of changes
from .92 to .93.

Diana

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
----------
X-Sun-Data-Type: PortableDocumentFormat-file
X-Sun-Data-Description: PortableDocumentFormat-file
X-Sun-Data-Name: revision.pdf
X-Sun-Encoding-Info: uuencode
X-Sun-Content-Lines: 177
From:	shchuang@sis.com.tw
Sent:	Tuesday, April 15, 1997 12:18 AM
To:	1394ohci-l@austin.ibm.com
Subject:	questions about cycle start and cycle inconsistent

Hi,


I have some questions about cycle start packet and cycle inconsistent.

If the LinkControl.cycleTimerEnable bit is not set while receiving a cycle
start packet, should we load the received cycle_time_data into the cycle
timer register?  If so, should this generate a cycleInconsistent condition?

Thanks for your time and answer,



Shiuh-Herng Chuang
From:	mjlu@sis.com.tw
Sent:	Tuesday, April 15, 1997 6:17 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Some IT DMA questions for OHCI v0.93

Hi,all:

I have some questions about Isochronous Transmit DMA in OHCI v0.93,page 100, 
section 9.4 :

1.It describes that "When an IT context has reached the end of its context 
program ans active is 0,setting wake will result in using the descriptor 
(not descriptor block).........". What does the descriptor mean? Does it 
mean OUTPUT_LAST* descriptors ?

2.It states that updating skipAddress and branchAddress is required in the 
last descriptor block to append descriptors to an IT context program. If 
hardware stops before context being appended, does hardware need to re-read 
the whole descriptor block to get the updated skipAddress and branchAddress 
or only re-read the last descriptor in the descriptor block when wake bit is 
set?

3.If a descriptor block includes OUTPUT_MORE_Immediate + OUTPUT_LAST, and 
this descriptor block is taking skipAddress as the next descriptor address, 
but the skipAddress in OUTPUT_MORE_Immediate contains zero Z value, thus this
context stops. When wake bit is set, which descriptor should hardware 
re-read, OUTPUT_MORE_Immediate or OUTPUT_LAST ? If the OUTPUT_MORE_Immediate 
descriptor is re-read, the skipAddress will be the next descriptor address 
though taking skip may not need now.

Thanks for your time and answers.



From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Tuesday, April 15, 1997 9:34 AM
To:	1394ohci-l@austin.ibm.com
Subject:	LinkControl.APhy


Question:

What does this bit tell us?  What sort of action is expected from the OHCI 
controller if this bit is set?

Joe
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Tuesday, April 15, 1997 9:38 AM
To:	1394ohci-l@austin.ibm.com
Subject:	HCControl.softReset


According to the description of this bit, software sets it to '1' and hardware 
clears it to '0'.  if that is true, shouldn't the bit be "rsu", not "rscu"?

Joe
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Tuesday, April 15, 1997 9:44 AM
To:	1394ohci-l@austin.ibm.com
Subject:	IntEvent.cycleTooLong


I'm a little confused on the description of this bit.  If a bus reset is very 
long (say several cycles) won't there be several cycles where no cycleStart was 
sent?  And if that is the case, do we really want to clear the cycleMaster bit 
because of the bus reset?  Shouldn't we just report this interrupt and keep 
moving on until software fixes the problem?

Joe
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Tuesday, April 15, 1997 9:48 AM
To:	1394ohci-l@austin.ibm.com
Subject:	LinkControl.cycleSource


What is the "external source" that the controller is supposed to use to roll 
over its internal cycle timer?  Is this bit supposed to imply that the 
controller uses external cycleStarts?  If that is true, isn't that obvious by 
cycleMaster being a '0'?

Joe
From:	daisy@sis.com.tw
Sent:	Tuesday, April 15, 1997 10:12 PM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Cc:	cmlin@sis.com.tw; daisy@sis.com.tw; rlai@sis.com.tw
Subject:	question about SelfIDComplete interrupt in OHCI0.93

Hi, all,

I have some questions about SelfIDComplete interrupt in OHCI 0.93,

In page 119, section 11.5, it says 
"if an error occurs in which selfID packets are not received and the
IntEvent.selfIDComplete is not set, software can determine that
the selfID phase should have completed ........"

My questions are,
1. Which kind of error this sentence is talking ? Dose the error includes
   the following two conditions, 
   1.1 no selfID packets received from 1394 bus,
   1.2 all selfID packets are lost due to FIFO overrun ?  
   
   Are there any other conditions cause this error ?

2. If the condition 1.2 occurs, I think SIDU will set the selfIDError bit,
   and IntEvent.selfIDComplete, and the "selfID phase" end when the interrupt
   bit is set, am I right ?

3. If the condition 1.1 occurs, I think the SIDU will set neither selfIDError
   nor IntEvent.selfIDComplete, the "selfID phase" end when sub-action gap
   occurs, am I right ?

4. Is there any relationship between selfIDError and IntEvent.selfIDComplete ?

5. Is there any relationship between set IntEvent.selfIDComplete and selfID
   phase end ?

In Table 6-1, it says, this interrupt bit will be set when 
"A selfID packet has been received. Will be generated at the end of the bus
 initialization process."

Could anyone explain this sentence more clearly ? 
I think this sentence is from SIDU point of view, not from link side, 
am I right ?

Thanks for the answer,

Y.J. Chao
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================
From:	jyshiuan@sis.com.tw
Sent:	Tuesday, April 15, 1997 10:40 PM
To:	1394ohci-l@austin.ibm.com
Subject:	IT cycleMatchEnable

Hi all:

  I have a question about IT cycleMatchEnable:

  1.  If several IT contexts are initialized using cycleMatchEnable,
       and reach the end of the descriptor block.
       so these contexts active will clear at the same cycle.

       Can SW wake these contexts by set wake and cycleMatchEnable at the
same time?
       If not, how does SW to wake these contexts simultaneously?

  2.  And the same case,
       If SW initializes these contexts by set wake at the same cycle ONLY,
       will these IT contexts all become active at the next cycle?
 
  Thanks for your time and answers.

===============================================
Jing-Yeh Shiuan
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
E-mail:     jyshiuan@sis.comp.tw
Phone:     886-3-5774922 ext 4302
Fax:          886-3-5790651
Email:      jyshiuan@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan, R. O. C.
==============================================
From:	mjlu@sis.com.tw
Sent:	Wednesday, April 16, 1997 12:26 AM
To:	1394ohci-l@austin.ibm.com
Subject:	A IT DMA question for OHCI v0.93 (II)

Hi,all:

I have a question about IT DMA in OHCI v0.93,page 100, section 9.5.1 :

It describes that "When the IntEvent.cycleInconsistent condition 
occurs,the IT DMA controller shall continue processing running contexts 
normally,.........". If the link side cycle timer has been changed by 
software in the cycle master node, how should the host side cycle timer be 
changed in the cycle master node ? Since according to OHCI v0.93,page 
47,Table 6-1, the cycleInconsistent interrupt event is reported only when 
cycle start was received,thus the cycle master node won't report 
cycleInconsistent event when software modifies the link side cycle timer. Or 
cycle master node need to report cycleInconsistent event in such a case.

Thanks for your time and answer.
From:	David Brief [David.Brief@nsc.com]
Sent:	Wednesday, April 16, 1997 1:37 AM
To:	Mei-Jiuan Lu
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: A IT DMA question for OHCI v0.93 (II)

My understanding is that the IntEvent.cycleInconsistent does not
occur for the cycle master node. The event descriptions says that
the event occurs when a "cycle start" is received - and a the cycle
master should not receive this packet.

-David Brief

Mei-Jiuan Lu wrote:
> 
> Hi,all:
> 
> I have a question about IT DMA in OHCI v0.93,page 100, section 9.5.1 :
> 
> It describes that "When the IntEvent.cycleInconsistent condition
> occurs,the IT DMA controller shall continue processing running contexts
> normally,.........". If the link side cycle timer has been changed by
> software in the cycle master node, how should the host side cycle timer be
> changed in the cycle master node ? Since according to OHCI v0.93,page
> 47,Table 6-1, the cycleInconsistent interrupt event is reported only when
> cycle start was received,thus the cycle master node won't report
> cycleInconsistent event when software modifies the link side cycle timer. Or
> cycle master node need to report cycleInconsistent event in such a case.
> 
> Thanks for your time and answer.
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Wednesday, April 16, 1997 10:21 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: LinkControl.APhy

     I second Joe's question.  If the bit is set, how does the link behave 
     differently?  What 1394a *link* feature would become active due to the 
     setting of the bit?
     
     Conversely, if the bit is not set, how should the link behave?  Since 
     not all 1394-1995 PHY's implement the PHY/LINK interface consistently, 
     a single bit can not allow the OHCI link to operate as a "universal 
     link".
     
     If universal operation is desired, consistency requires that all of 
     the configuration bits necessary for universal operation would have to 
     be added to the OHCI spec.
     
     Alternatively, the OHCI link could simply assume P1394A operation.  If 
     vendor want to implement a universal link, then vendor specific bits 
     could be added independent of the spec.  Since these configurations 
     would have to be set by the BIOS, I don't see that it needs to be 
     standardized or required for all OHCI implementations.
     
     I think the only requirement we want is that OHCI compliant silicon 
     MUST work with a P1394a PHY.  Operation with other PHY's is an option 
     of the vendor.
     
     Jerry Hauck
     Intel
     (408) 765-5528
     jerry_hauck@ccm.sc.intel.com


______________________________ Reply Separator _________________________________
Subject: LinkControl.APhy
Author:  leew@austin.ibm.com at SMTPGATE
Date:    4/15/97 9:34 AM


Question:
     
What does this bit tell us?  What sort of action is expected from the OHCI 
controller if this bit is set?
     
Joe
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Wednesday, April 16, 1997 10:38 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: IntEvent.cycleTooLong

     Joe,
     
     I believe the IntEvent.cycleTooLong bit has nothing to do with lost 
     cycles or cycle start packets.  One situation this event detects is 
     when two independent buses are joined and the combined isochronous 
     traffic exceeds the 125 uSec maximum period between cycle starts.  If 
     this case arises, asynchronous traffic (with the exception of the 
     cycle Start packet) can not occur.  Only recover is to stop issuing 
     cycle starts.
     
     I'm guessing that the reason the 125 usec is tested rather than 100 
     usec (which is the max allowable iso traffic) is so that interruption 
     of iso traffic is minimized. As long as one asynchronous packet 
     besides cycle start can be sent each period, the P1394 rule which 
     requires each isochronous device to reconfirm its bandwidth allocation 
     after a bus reset can be implemented.  If the combined bandwidth after 
     a bus reset is >100 usec and <125 usec, then most isochronous 
     transfers will be uninterrupted, and only the last few streams which 
     try and reserve bandwidth will have to turn off.  This is better than 
     killing all isochronous traffic because the iso period lasted > 100 
     usec.
     
     Jerry Hauck
     Intel Corportaion
     (408) 765-5528
     jerry_hauck@ccm.sc.intel.com
______________________________ Reply Separator _________________________________
Subject: IntEvent.cycleTooLong
Author:  leew@austin.ibm.com at SMTPGATE
Date:    4/15/97 9:44 AM


I'm a little confused on the description of this bit.  If a bus reset is very 
long (say several cycles) won't there be several cycles where no cycleStart 
was
sent?  And if that is the case, do we really want to clear the cycleMaster bit 
because of the bus reset?  Shouldn't we just report this interrupt and keep 
moving on until software fixes the problem?
     
Joe
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Thursday, April 17, 1997 10:27 AM
To:	1394ohci-l@austin.ibm.com
Subject:	lockRespErr


This wasn't in the revision.pdf file, but I notices there is a 'lockRespErr' bit
in the IntEvent register.  What will software do when it sees this interrupt?

If this interrupt really is required, then I believe the mask register needs to 
be updated.  Currently, bit 9 of the mask register is listed as 'reserved'.

joe
From:	Diana.Klashman@East.Sun.COM
Sent:	Thursday, April 17, 1997 10:51 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: lockRespErr

>From Joseph_A_Bennett@ccm.fm.intel.com Thu Apr 17 13:34:14 1997
>
>This wasn't in the revision.pdf file, but I notices there is a 'lockRespErr' bit
>in the IntEvent register.  What will software do when it sees this interrupt?
>
>If this interrupt really is required, then I believe the mask register needs to 
>be updated.  Currently, bit 9 of the mask register is listed as 'reserved'.
>
>joe
>

Software should only see this interrupt if it's the Isoch Resource Mgr.
This interrupt indicates that there _may_ be orphaned bandwidth or orphaned
channels in the IRM CSR regs.  Sw can ignore it or can cause a bus-reset
to force re-allocation of the IRM resources.

Table 6-2 (bit 9) will be fixed in .94.

Diana
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Thursday, April 17, 1997 11:50 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[2]: IntEvent.cycleTooLong


Text item: 



Jerry,

I don't think I was too clear in the original message.  I was concerned that if 
there was 'cycleTooLong' occurring due to long bus resets, then after bus reset 
there may be several cycles before software gets in and turns the 'cycleMaster' 
bit back on.

I would have figured that if software saw 'cycleTooLong' interrupt often enough,
it would take the responsibility for shutting down the cycleMaster and fixing 
the bus, and that the hardware should not do this on its own.

Perhaps what I am confused about is the length of a bus reset, and whether a 
subaction gap is detected between each Self-ID packet.

______________________________ Reply Separator _________________________________
Subject: Re: IntEvent.cycleTooLong
Author:  leew@austin.ibm.com at SMTPGATE
Date:    4/16/97 10:38 PM


     Joe,

     I believe the IntEvent.cycleTooLong bit has nothing to do with lost 
     cycles or cycle start packets.  One situation this event detects is 
     when two independent buses are joined and the combined isochronous 
     traffic exceeds the 125 uSec maximum period between cycle starts.  If 
     this case arises, asynchronous traffic (with the exception of the 
     cycle Start packet) can not occur.  Only recover is to stop issuing 
     cycle starts.

     I'm guessing that the reason the 125 usec is tested rather than 100 
     usec (which is the max allowable iso traffic) is so that interruption 
     of iso traffic is minimized. As long as one asynchronous packet 
     besides cycle start can be sent each period, the P1394 rule which 
     requires each isochronous device to reconfirm its bandwidth allocation 
     after a bus reset can be implemented.  If the combined bandwidth after 
     a bus reset is >100 usec and <125 usec, then most isochronous 
     transfers will be uninterrupted, and only the last few streams which 
     try and reserve bandwidth will have to turn off.  This is better than 
     killing all isochronous traffic because the iso period lasted > 100 
     usec.

     Jerry Hauck
     Intel Corportaion
     (408) 765-5528
     jerry_hauck@ccm.sc.intel.com
______________________________ Reply Separator ________________________________ 
_
Subject: IntEvent.cycleTooLong
Author:  leew@austin.ibm.com at SMTPGATE 
Date:    4/15/97 9:44 AM


I'm a little confused on the description of this bit.  If a bus reset is very 
long (say several cycles) won't there be several cycles where no cycleStart 
was
sent?  And if that is the case, do we really want to clear the cycleMaster bit 
because of the bus reset?  Shouldn't we just report this interrupt and keep 
moving on until software fixes the problem?

Joe

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: Re: IntEvent.cycleTooLong
To: 1394ohci-l@austin.ibm.com
Message-ID: <Thu, 17 Apr 97 09:09:16 PDT_18@ccm.sc.intel.com>
From: Jerry Hauck <Jerry_Hauck@ccm.sc.intel.com>
Date: Wed, 16 Apr 97 22:38:00 PDT
Received: by ccm.sc.intel.com (ccmgate 3.2 #2) Thu, 17 Apr 97 09:09:35 PDT
Received: (from ccmgate@localhost) by prairie.sc.intel.com (8.7.3/8.7.3) id JAA0
0808 for 1394ohci-l@austin.ibm.com; Thu, 17 Apr 1997 09:09:35 -0700 (PDT)
Received: from prairie.sc.intel.com by imssc1.sc.intel.com (8.8.4/10.0i); Thu, 1
7 Apr 1997 16:11:48 GMT
Received: from imssc1.sc.intel.com (imssc1.sc.intel.com [143.183.152.7]) by netm
ail1.austin.ibm.com (8.6.12/8.6.11) with SMTP id MAA31827 for <1394ohci-l@austin
.ibm.com>; Thu, 17 Apr 1997 12:20:01 -0500
Received: from netmail1.austin.ibm.com by calliope.fm.intel.com (8.8.4/10.0i); T
hu, 17 Apr 1997 17:27:42 GMT
Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) by
fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id KAA20962; Thu, 17 Apr 1997 10:27
:56 -0700 (PDT)
Return-Path: leew@austin.ibm.com
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Thursday, April 17, 1997 3:04 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Asynch Transmit xferstatus Update


A couple of questions on AT xferstatus Update:

    On page 58 of 0.93, OHCI states to update the xferStatus field of the 
    descriptor upon completion of the OUTPUT_LAST* descriptor.  You really don't 
    update xferStatus until the ack is received, right?
    
    If the command receives an ack_busy or ack_data_err, which causes us to 
    retry the command on the wire, do we still want to update the descriptor?  
    This means that software not only has to see that a descriptor was executed 
    by looking at the 'run' bit in the xferStatus field, but also has to parse 
    the ack/err_code to see that the command actually completed.  Does this 
    sound correct?
    
Thanks,
Joe
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Friday, April 18, 1997 8:05 AM
To:	1394ohci-l@austin.ibm.com
Subject:	LinkEnable.cycleSource


I'm not sure I understand the reason for this bit.  If "external source" refers 
to an 8kHz input pin, how does OHCI know whether the component has that external
source or not, and why would it care if it did?

Joe
From:	Mark Knecht [Mark_Knecht@phoenix.com]
Sent:	Friday, April 18, 1997 10:25 AM
To:	'1394ohci-l@austin.ibm.com'
Subject:	Subscribe

subscribe

help
From:	dfensore@thoreau.nsc.com
Sent:	Friday, April 18, 1997 1:41 PM
To:	Joseph_A_Bennett@ccm.fm.intel.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: Asynch Transmit xferstatus Update

Hi Joe,

    I don't think the Host Controller should update the status until
it completes the transfer by receiving a "non-retry" status or
exhausting the retry count. Software cannot distinguish between
intermediate status written between retries and the final status
written when the Host Controller exhausts the retry
counter. Therefore, writing intermediate status will make it difficult
for software to tell when a given descriptor has completed. In
addition, I can't think of any benefit to software of seeing the
intermediate status.

    I think the Table 3-2 describes this behavior by stating that a
packet receives one of the ack_busy event codes only after "max
ATRetries" attempts.

Thanks and Regards,

- Dave

-- 
David J. Fensore  MS 10-26    Phone: (207) 541-8773
National Semiconductor Corp.  Email: dfensore@thoreau.NSC.COM
333 Western Avenue            
South Portland, Maine 04106   (Advanced Development Center)
_______________________________________________________________________
> 
>  From: Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com>
>  Message-Id: <Thu, 17 Apr 97 15:08:15 PDT_4@ccm.hf.intel.com>
>  To: 1394ohci-l@austin.ibm.com
>  Subject: Asynch Transmit xferstatus Update
> 
> 
>  A couple of questions on AT xferstatus Update:
> 
>      On page 58 of 0.93, OHCI states to update the xferStatus field of
>      the descriptor upon completion of the OUTPUT_LAST* descriptor.
>      You really don't update xferStatus until the ack is received,
>      right?  If the command receives an ack_busy or ack_data_err,
>      which causes us to retry the command on the wire, do we still
>      want to update the descriptor?  This means that software not only
>      has to see that a descriptor was executed by looking at the 'run'
>      bit in the xferStatus field, but also has to parse the
>      ack/err_code to see that the command actually completed.  Does
>      this sound correct?
> 
>  Thanks,
>  Joe
> 
> 
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Friday, April 18, 1997 1:57 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: lockRespErr

     Most likely, software will issue a bus reset when lockRespErr occurs.  
     A reset is the only sure way to remove the ambiguity when an ack is 
     not received for a lock response from some bus management registers.  
     For example, if a device (including OHCI) attempts to reserve iso 
     bandwidth and the acknowledge never occurs, there is no way to know if 
     the lock response was correctly received or not.  Depending on any 
     subsequent assumption, bandwidth could be either over or under 
     subscribed.
     
     An interrupt was chosen over a hardware issued bus reset since it had 
     the least impact to current hardware (OHCI hardware has no 
     reason/ability to autonomously generate a bus reset currently) and 
     wasn't expected to occur often (or ever).
     
     Regards,
     Jerry Hauck
     Intel Corp.
     jerry_hauck@ccm.sc.intel.com
     
     
______________________________ Reply Separator _________________________________
Subject: lockRespErr
Author:  leew@austin.ibm.com at SMTPGATE 
Date:    4/17/97 10:27 AM
     
     
This wasn't in the revision.pdf file, but I notices there is a 'lockRespErr' 
bit
in the IntEvent register.  What will software do when it sees this interrupt?
     
If this interrupt really is required, then I believe the mask register 
needs to
be updated.  Currently, bit 9 of the mask register is listed as 'reserved'.
     
joe
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Friday, April 18, 1997 1:55 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[3]: IntEvent.cycleTooLong

     Joe,
     
     If you assume a bus reset causes the cycleTooLong timer to be reset, 
     does your concern go away?
     
     I believe (and hope) that cycleTooLong indicates that the time between 
     a cycleStart packet and the next subaction gap exceeded 125 uSec.  Bus 
     resets, no matter how long or how frequent, can not cause this 
     condition.  Bus resets can only interrupt isochronous cycles in 
     progress (which should force a reset of the cycleTooLong timer) and 
     delay the expected beginning of a future cycle.  CycleTooLong only 
     occurs if too many isochronous devices try to send packets in the same 
     period.
     
     Since CycleTooLong doesn't occur as a side-effect of any "catch-up" 
     occurring after a reset, I see no reason to expect that its infrequent 
     occurrence is okay.  A single event is an indication that isochronous 
     bandwidth management is royally screwed up.  "Often enough" in your 
     note below should be replaced with "once".  Thus either hardware or 
     software would have to disable cycle starts immediately to begin 
     recovery.  Implementation in hardware allows asnychronous operations 
     to resume more quickly.
     
     Jerry Hauck
     Intel Corp.
     jerry_hauck@ccm.sc.intel.com
     
______________________________ Reply Separator _________________________________
Subject: Re[2]: IntEvent.cycleTooLong
Author:  leew@austin.ibm.com at SMTPGATE
Date:    4/17/97 11:50 AM


Jerry,
     
I don't think I was too clear in the original message.  I was concerned 
that if
there was 'cycleTooLong' occurring due to long bus resets, then after 
bus reset
there may be several cycles before software gets in and turns the 
'cycleMaster'
bit back on.
     
I would have figured that if software saw 'cycleTooLong' interrupt 
often enough,
it would take the responsibility for shutting down the cycleMaster and fixing 
the bus, and that the hardware should not do this on its own.
     
Perhaps what I am confused about is the length of a bus reset, and whether a 
subaction gap is detected between each Self-ID packet.
     
______________________________ Reply Separator ________________________________ 
_
Subject: Re: IntEvent.cycleTooLong
Author:  leew@austin.ibm.com at SMTPGATE 
Date:    4/16/97 10:38 PM
     
     
     Joe,
     
     I believe the IntEvent.cycleTooLong bit has nothing to do with lost 
     cycles or cycle start packets.  One situation this event detects is 
     when two independent buses are joined and the combined isochronous 
     traffic exceeds the 125 uSec maximum period between cycle starts.  If 
     this case arises, asynchronous traffic (with the exception of the 
     cycle Start packet) can not occur.  Only recover is to stop issuing 
     cycle starts.
     
     I'm guessing that the reason the 125 usec is tested rather than 100 
     usec (which is the max allowable iso traffic) is so that interruption 
     of iso traffic is minimized. As long as one asynchronous packet 
     besides cycle start can be sent each period, the P1394 rule which 
     requires each isochronous device to reconfirm its bandwidth allocation 
     after a bus reset can be implemented.  If the combined bandwidth after 
     a bus reset is >100 usec and <125 usec, then most isochronous 
     transfers will be uninterrupted, and only the last few streams which 
     try and reserve bandwidth will have to turn off.  This is better than 
     killing all isochronous traffic because the iso period lasted > 100 
     usec.
     
     Jerry Hauck
     Intel Corportaion
     (408) 765-5528
     jerry_hauck@ccm.sc.intel.com
______________________________ Reply Separator ________________________________
     
_
Subject: IntEvent.cycleTooLong
Author:  leew@austin.ibm.com at SMTPGATE 
Date:    4/15/97 9:44 AM
     
     
I'm a little confused on the description of this bit.  If a bus reset is very 
long (say several cycles) won't there be several cycles where no cycleStart 
was
sent?  And if that is the case, do we really want to clear the cycleMaster bit 
because of the bus reset?  Shouldn't we just report this interrupt and keep 
moving on until software fixes the problem?
     
Joe
From:	PJohansson@aol.com
Sent:	Monday, April 21, 1997 11:42 AM
To:	1394ohci-l@austin.ibm.com
Cc:	Jerry_Hauck@ccm.sc.intel.com
Subject:	Re: Re[3]: IntEvent.cycleTooLong

In a message dated 97-04-18 19:57:59 EDT, Jerry_Hauck@ccm.sc.intel.com (Jerry
Hauck) writes:

<<Thus either hardware or software would have to disable cycle starts
immediately to begin recovery.  Implementation in hardware allows
asnychronous operations to resume more quickly.>>

I'm sure this is very well known all ready amongst you barbarians, but it's
so important it doesn't hurt to say it again.

1394-1995 requires that the cycle master clear the CMSTR bit if cycle too
long is detected. Actually, I don't have the current standard open in front
of me: if 1394-1995 doesn't say this, I expect P1394a will.

Regards,

Peter Johansson

From:	DavidW@bangate.compaq.com
Sent:	Monday, April 21, 1997 4:24 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Re: IT DMA underrun status

Joe is correct about cycle skips on an underrun.  However, SW can tell which 
channel had the underrun because the status in the OUTPUT_LAST_* will get set 
to evt_underrun.  Then, the 'current' cycle's packets for the rest of the 
contexts will be placed in the output FIFO and sent in a future cycle.  This 
will force cycle lost processing.  If the 'current' cycle's packets cause an 
underrun in a future cycle (packet delayed and then underruns) then the packet 
will still get set to indicate that an underrun occurred and packets will get 
slipped some more.  In short, when we start getting underruns, all hell breaks 
lose. 

Robert's original problem statement indicates that some people don't seem to 
understand that one can't simple drop iso packets when they become 
'inconvenient' to deal with.  OHCI designs need to be done on the basis that 
iso packets will NEVER be lost by the host controller (NEVER being a 
subjective term which I think of as 1 in a billion.)  Designs that assume an 
occasional loss (1 in a million or 1 in 100,000)  will NOT survive in the 
market.  (One failure every 100,000 packets will cause a perceptible audio pop 
every 12.5 seconds and that's not acceptable even for cheap stuff.) 

David


Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
| 
| 
| Text item: 
| 
| 
| Robert,
| 
| I am not in support of this idea.  When a FIFO underrun happens, we will 
fall 
| out of the isoch phase, and an interrupt will be generated (cycleLost).  
| Therefore, software will know that something was up.  Also note that the 
host 
| controller always takes cycle skips together, so you are going to have skips 

| taken on contexts that were working just fine, but have to skip because one 
| context was ill behaved (or there was large PCI latency, or whatever).
| 
| Therefore, if we have a lost transmission, all contexts will have reported 
that 
| there was a loss.  Because of this, I don't think software could figure out 
who 
| was bad very easily.  We would need some form of per-context FIFO underrun 
| interrupt, or software would go to the device and see that the receiver had 
a 
| CRC error.
| 
| Finally, if you lost some data on a packet you said went out (because you 
| updated the status when you put the packet into the FIFO) you will see that 
| future descriptors will not have been executed because the skip will have 
been 
| taken later on.
| 
| I hope this isn't too confusing, but my point is that software has several 
ways 
| of knowing stuff didn't go out, but I don't think it gets any value from 
knowing
| which particular packet, at any time, failed.
| 
| Joe
| ___________________________________________________________________________
| 
| Hi,
| 
| An interesting little detail in the IT DMA was recently pointed out to 
| me:  the IT contexts don't report transmit underruns.  While it seems 
| reasonable to structure the skip processing on the assumption that 
| underruns "never happen", it seems equally dangerous to discard 
| underrun events when they do happen.  I'm at a loss to see how a 
| single, common driver (ala WDM) can provide robust performance from HC 
| implementations of varying buffer capacities without getting txunderrun 
| feedback.
| 
| Since the underruns appear as CRC errors at the receiver the 1394 user 
| may be misled as to the cause of the problem.  To make matters worse, 
| when the iso channel is received into an OpenHCI IR context using 
| bufferFill mode, the bad packets are backed out.  Packets then just 
| disappear without any indication of the cause.  At the last 
| face-to-face it was mentioned that some HCs have shown buffer 
| undersizing problems at just 100Mbps. What can we expect at 400Mbps?
| 
| The best solution (IMHO) is to include the ability to indicate transmit 
| underrun in the eventCode when writing back status to the ITDMA 
| descriptors.  Here's an attempt at a conceptual description of how IT 
| DMA contexts can write back underrun status. Implementations can 
| achieve this logical behavior using registers, scratchpad RAM or
| FIFOs.
| 
|    The DMA side must save a writeback pointer for each packet placed 
|    into the isoTxFIFO.  Since the IT DMA contexts can work a maximum of 
|    two cycles ahead of the link, each IT DMA context needs to reserve 
|    space for two writeback pointers.  When the link side completes 
|    packet transmission it reports transmit status back to the DMA side 
|    which, in turn, writes the transmit status into host memory using 
|    the saved writeback pointer.
| 
| The rest of the algorithms are unchanged.  This behavior means that the 
| txstatus writeback will be delayed until the link actually transmits 
| the packet.  Software needs to be aware that two Z-blocks may be 
| "in-flight".  A nice side-effect is that it becomes straightforward for 
| the HC to write back the actual timestamp present at packet 
| transmission time, instead of a DMA side approximation.  Another nice 
| side-effect is that the host bus accesses for status writeback are 
| decoupled from the IT descriptor fetching, so when the IT DMA 
| processing gets behind it isn't burdened with the overhead of 
| performing the writeback accesses "in-line" with the descriptor 
| fetching.
| 
| This seems like the "right thing to do" to me.
| 
|      - Robert
| 
| --
| Robert L. Macomber MS 10-26   Phone: (207) 541-4677 
| National Semiconductor Corp.  Fax:   (207) 541-6108
| 333 Western Avenue            Email: macomber@thoreau.nsc.com 
| South Portland, Maine 04106   Advanced Development Center
| 
| Text item: External Message Header
| 
| The following mail header is for administrative use
| and may be ignored unless there are problems.
| 
| ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
| 
| Content-Type: text
| X-Mailer: ELM [version 2.4 PL24]
| Organization: National Semiconductor (Advanced Development Center)
| Date: Fri, 18 Apr 1997 16:33:58 -0400 (EDT)
| To: hciboys-l@austin.ibm.com
| Subject: IT DMA underrun status
| Message-Id: <9704182036.AA28867@thoreau.nsc.com>
| From: macomber@thoreau.nsc.com (Robert Macomber)
| Received: from emerson.nsc.com by thoreau.nsc.com (4.1/SMI-4.1)
|      id AA28867; Fri, 18 Apr 97 16:36:05 EDT
| Received: from thoreau.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP
|      id AA10687 for hciboys-l@austin.ibm.com; Fri, 18 Apr 97 13:30:44 -0700
| Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2)
|      id xma024316; Fri, 18 Apr 97 13:28:59 -0700
| Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id 
NAA2477
| 0 for <hciboys-l@austin.ibm.com>; Fri, 18 Apr 1997 13:29:46 -0700
| Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by 
netma
| il1.austin.ibm.com (8.6.12/8.6.11) with SMTP id PAA21883 for 
<hciboys-l@austin.i
| bm.com>; Fri, 18 Apr 1997 15:31:43 -0500
| Received: from netmail1.austin.ibm.com by calliope.fm.intel.com 
(8.8.4/10.0i); F
| ri, 18 Apr 1997 20:37:22 GMT
| Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) 
by
| fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id NAA17503; Fri, 18 Apr 1997 
13:37
| :38 -0700 (PDT)
| Return-Path: leew@austin.ibm.com
| 
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, April 22, 1997 8:46 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Some IT DMA questions for OHCI v0.93

Replies embedded.

David Wooten

mjlu@sis.com.tw (Mei-Jiuan Lu) Wrote:
| 
| Hi,all:
| 
| I have some questions about Isochronous Transmit DMA in OHCI v0.93,page 100, 

| section 9.4 :
| 
| 1.It describes that "When an IT context has reached the end of its context 
| program ans active is 0,setting wake will result in using the descriptor 
| (not descriptor block).........". What does the descriptor mean? Does it 
| mean OUTPUT_LAST* descriptors ?

A descriptor is a 16 byte entity.  A descriptor block contains one or more 
descriptors.  The descriptor that is used in this case (active = 0) is the 
descriptor that contained the Z=0 that caused active to be cleared.  That 
descriptor can either be the first in a descriptor block (the skip address) or 
the last in a descriptor block (OUTPUT_LAST_*) depending on 'execution' path.

| 
| 2.It states that updating skipAddress and branchAddress is required in the 
| last descriptor block to append descriptors to an IT context program. If 
| hardware stops before context being appended, does hardware need to re-read 
| the whole descriptor block to get the updated skipAddress and branchAddress 
| or only re-read the last descriptor in the descriptor block when wake bit is 

| set?

Minimally, the HC must read the location from which it read the branch address 
that had a Z value of zero.  It does not have to read more.  This is either in 
the first descriptor or the last descriptor in a descriptor block.


| 
| 3.If a descriptor block includes OUTPUT_MORE_Immediate + OUTPUT_LAST, and 
| this descriptor block is taking skipAddress as the next descriptor address, 
| but the skipAddress in OUTPUT_MORE_Immediate contains zero Z value, thus 
this
| context stops. When wake bit is set, which descriptor should hardware 
| re-read, OUTPUT_MORE_Immediate or OUTPUT_LAST ? If the OUTPUT_MORE_Immediate 

| descriptor is re-read, the skipAddress will be the next descriptor address 
| though taking skip may not need now.

Reread the address that contained the Z=0 value that caused active=0 for the 
context.

| 
| Thanks for your time and answers.
| 
| 
| 
| 
| 
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Tuesday, April 22, 1997 8:48 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Restatement of Questions


I posted three questions last week.  I haven't heard a response from you all, 
due to the TA and WinHEC, so I thought I'd re-ask:

LinkControl.APhy

        What does this bit tell us?  What sort of action is expected 
        from the OHCI controller if this bit is set?

Linkenable.cycleSource

        I'm not sure I understand the reason for this bit.  If "external 
        source" refers to an 8kHz input pin, how does OHCI know whether 
        the component has that external source or not, and why would it 
        care if it did?

HCControl.softReset

        According to the description of this bit, software sets it to '1' 
        and hardware clears it to '0'.  if that is true, shouldn't the 
        bit be "rsu", not "rscu"?

Thanks,

Joe
From:	Mark Knecht [Mark_Knecht@phoenix.com]
Sent:	Tuesday, April 22, 1997 9:22 AM
To:	'1394ohci-l@austin.ibm.com'
Subject:	Subscribe Mark_Knecht@phoenix.com

Subscribe Mark_Knecht@phoenix.com
From:	Vilas Bhade [vilas@wipro.com]
Sent:	Tuesday, April 22, 1997 9:22 AM
To:	1394ohci-l@austin.ibm.com; 'PJohansson@aol.com'
Cc:	Jerry_Hauck@ccm.sc.intel.com
Subject:	RE: Re[3]: IntEvent.cycleTooLong

To:ALL

1394-1995 does not say or give any relation between cmstr and cycle too long.
OHCI does talk about this. I guess we never discuss this issue in 1394A also.

Do we have plan to take this issue in the next meeting. I agree that it is logical to clear this bit.

Thx and Regds
Vilas

Wipro Ltd
10670 N.Tantau Ave #201
Cupertino CA 95014

----------
From:  PJohansson@aol.com[SMTP:PJohansson@aol.com]
Sent:  Monday, April 21, 1997 7:42 AM
To:  1394ohci-l@austin.ibm.com
Cc:  Jerry_Hauck@ccm.sc.intel.com
Subject:  Re: Re[3]: IntEvent.cycleTooLong

In a message dated 97-04-18 19:57:59 EDT, Jerry_Hauck@ccm.sc.intel.com (Jerry
Hauck) writes:

<<Thus either hardware or software would have to disable cycle starts
immediately to begin recovery.  Implementation in hardware allows
asnychronous operations to resume more quickly.>>

I'm sure this is very well known all ready amongst you barbarians, but it's
so important it doesn't hurt to say it again.

1394-1995 requires that the cycle master clear the CMSTR bit if cycle too
long is detected. Actually, I don't have the current standard open in front
of me: if 1394-1995 doesn't say this, I expect P1394a will.

Regards,

Peter Johansson



From:	DavidW@bangate.compaq.com
Sent:	Tuesday, April 22, 1997 10:17 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Restatement of Questions

Responses embedded.

David Wooten

Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
| 
| 
| I posted three questions last week.  I haven't heard a response from you 
all, 
| due to the TA and WinHEC, so I thought I'd re-ask:
| 
| LinkControl.APhy
| 
|         What does this bit tell us?  What sort of action is expected 
|         from the OHCI controller if this bit is set?

We don't know yet.  We put this in as a placeholder because it looked to us 
like there might be some special actions required of a link that was attached 
to an A PHY.  Some people though it would be nice to have the ability to work 
with old PHY's at least until the time we had fully compliant A PHYs.  If this 
turns out to be unnecessary, we might take it out or we might just decide to 
hard wire it to '1'.

| 
| Linkenable.cycleSource
| 
|         I'm not sure I understand the reason for this bit.  If "external 
|         source" refers to an 8kHz input pin, how does OHCI know whether 
|         the component has that external source or not, and why would it 
|         care if it did?

Nominally, this is used when one wants to have two or more 1394 host 
controllers in a system a have them use the same cycle interval.  I don't know 
how one tells if this feature is present or attached other than to set the bit 
and then check to see if cycles are happening.  I'd vote to make this 
optional.

Since this is a Pele relic, I think we should hear from Apple about how it is 
or isn't being used before we take it out or make it optional.

| 
| HCControl.softReset
| 
|         According to the description of this bit, software sets it to '1' 
|         and hardware clears it to '0'.  if that is true, shouldn't the 
|         bit be "rsu", not "rscu"?

Oh, I suppose.

| 
| Thanks,
| 
| Joe
| 
From:	PJohansson@aol.com
Sent:	Tuesday, April 22, 1997 10:27 AM
To:	vilas@wipro.com; 1394ohci-l@austin.ibm.com
Cc:	Jerry_Hauck@ccm.sc.intel.com
Subject:	Re: Re[3]: IntEvent.cycleTooLong

In a message dated 97-04-22 12:35:25 EDT, vilas@wipro.com (Vilas Bhade)
writes:

<<1394-1995 does not say or give any relation between cmstr and cycle too
long. OHCI does talk about this. I guess we never discuss this issue in 1394A
also.>>

I will add a new clause to P1394a to address "Cycle too long".

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com
From:	jyshiuan@sis.com.tw
Sent:	Tuesday, April 22, 1997 7:14 PM
To:	1394ohci-l@austin.ibm.com
Subject:	IRDMA /cycleInconsistent

Hi all:

   I have a question about the IRDMA and cycleInconsistent

  The OHCI093 said that the ITDMA will be active immediately
  if a IntEvent.cycleInconsistent condition occures.

  Will the IRDMA has the same behavior?
  If we set the cycleMatchEnable for a IRDMA context,
  and receive a IntEvent.cycleInconsistent condition,
  Will the IRDMA disable the cycleMatchEnable and become active,
  or just wait until the contextMatch register matches 
  the 13-bit cycleCount in the cycleStart packet.

  Thanks,

===============================================
Jing-Yeh Shiuan
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
E-mail:     jyshiuan@sis.comp.tw
Phone:     886-3-5774922 ext 4302
Fax:          886-3-5790651
Email:      jyshiuan@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan, R. O. C.
==============================================
From:	cylin@sis.com.tw
Sent:	Tuesday, April 22, 1997 7:28 PM
To:	1394ohci-l@austin.ibm.com
Subject:	zero length packet for IR

Hi,

I have some questions about zero length packet for IR according to OHCI0.93:
1. In page 107, Sec. 10.2.2.1, it states that "In packet-per-buffer mode,
   s=1 the xferStatus and resCount fields are updated only in the
   descriptor for the buffer which recieves the last byte of the packet."
   If for a IR context, contextControl.isoHeader=0 and the received
   packet has no data, should HW update the status and skip the rest of
   the buffers given in the descriptor block?
2. According to page 124, Sec. 13.2.6, "If a data write error occurs for a
   context that is in packet-per-buffer mode, the Host Controller will set
   ContextControl.event to evt_data_wrte or evt_overrun... Any remaining
   data in the input FIFO is discarded." If overrun occurs when a packet
   is being received and before a host cycle is attempted for data write, 
   should HW discard the entire packet? If so, should HW update status for
   this overrun packet and skip buffers?
3. How does the first case apply to a context in bufferFill mode? Should 
   HW update the status? The 2nd case does not apply to bufferFill mode 
   since the packet will be backed out and not appear to SW.

Thanks,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	yehiel engel [YENGEL@HAIFASC3.HAIFA.IBM.COM]
Sent:	Wednesday, April 23, 1997 5:21 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Question about buffer fill interrupt

=============================================

Hello all

I have a question concerning the interrupt mechanism in
Buffer Fill mode. As an answer to my previous question,
Diana said that an interrupt for a descriptor is
generated only if the descriptor resCount is zero (after
status update). Suppose that we have a packet that resides
in 3 (or more) buffer descriptors. After updating the status
for this packet we should generate interrupt for the first
descriptor (assuming i field is 2'b11). My question is: should
we also generate interrupts for the intermediate descriptors
(descriptors that are not the first and final descriptors for the packet).
My assumption is that we should not generate interrupt for these
descriptors. According to this assumption SW should set the i field
for every descriptor in the context, since it does not have
a knowledge about the order and the size of the incoming packets.
If my assumption is wrong, we should save the i field for every
intermediate descriptor buffer and generate an interrupt (maybe
more then one) after the status update phase.
Any comment will be appreciated.

Regards
Yehiel Engel
From:	jyshiuan@sis.com.tw
Sent:	Wednesday, April 23, 1997 3:04 AM
To:	1394ohci-l@austin.ibm.com
Subject:	copyRightDataEnable

Hi all:

   I have a question about the copyRightDataEnable bit in IRDMA contextMatch
register.

  In OHCI093, it said, If set, this bit enables the reception of copyrihgt
Information.
  what is the "copyrihgt Information"?
  
  Does this mean that 
  when this bit is set, then only the packet that "tcode= C" is accepted?

  Thanks.


  

===============================================
Jing-Yeh Shiuan
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
E-mail:     jyshiuan@sis.comp.tw
Phone:     886-3-5774922 ext 4302
Fax:          886-3-5790651
Email:      jyshiuan@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan, R. O. C.
==============================================
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, April 23, 1997 7:14 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: copyRightDataEnable

When this bit is set a context may receive both tcode A and tcode C packets.  
When this bit is not set, then the context may only receive tcode A packets.

David Wooten

jyshiuan@sis.com.tw (jyshiuan) Wrote:
| 
| Hi all:
| 
|    I have a question about the copyRightDataEnable bit in IRDMA contextMatch
| register.
| 
|   In OHCI093, it said, If set, this bit enables the reception of copyrihgt
| Information.
|   what is the "copyrihgt Information"?
|   
|   Does this mean that 
|   when this bit is set, then only the packet that "tcode= C" is accepted?
| 
|   Thanks.
| 
| 
|   
| 
| ===============================================
| Jing-Yeh Shiuan
| Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.
| E-mail:     jyshiuan@sis.comp.tw
| Phone:     886-3-5774922 ext 4302
| Fax:          886-3-5790651
| Email:      jyshiuan@sis.com.tw
| Address: No 16, Creation Rd 1, 
|                  Science-based Industrial Park,
|                  Hsin Chu, Taiwan, R. O. C.
| ==============================================
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, April 23, 1997 7:00 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: zero length packet for IR

Respopnses embedded.

David Wooten



cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi,
| 
| I have some questions about zero length packet for IR according to OHCI0.93:
| 1. In page 107, Sec. 10.2.2.1, it states that "In packet-per-buffer mode,
|    s=1 the xferStatus and resCount fields are updated only in the
|    descriptor for the buffer which recieves the last byte of the packet."
|    If for a IR context, contextControl.isoHeader=0 and the received
|    packet has no data, should HW update the status and skip the rest of
|    the buffers given in the descriptor block?

Yes.

| 2. According to page 124, Sec. 13.2.6, "If a data write error occurs for a
|    context that is in packet-per-buffer mode, the Host Controller will set
|    ContextControl.event to evt_data_wrte or evt_overrun... Any remaining
|    data in the input FIFO is discarded." If overrun occurs when a packet
|    is being received and before a host cycle is attempted for data write, 
|    should HW discard the entire packet? If so, should HW update status for
|    this overrun packet and skip buffers?

The overrun conditoin is seen by the link side of the FIFO not the host side.  
The host side will unload data and 'discover' a token in the FIFO that the 
link side has inserted to indicate the overrun condition.  So, the host side 
will store all data that it unloads up to the token.


| 3. How does the first case apply to a context in bufferFill mode? Should 
|    HW update the status? The 2nd case does not apply to bufferFill mode 
|    since the packet will be backed out and not appear to SW.

I don't think it matters to SW whether you update the status or not, so just 
do what's easiest for HW.

| 
| Thanks,
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, April 23, 1997 7:11 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Question about buffer fill interrupt

Since the first and intermediate descriptors are retired by the same packet, 
the single interrupt for the first descriptor write to 0 is the interrupt for 
the intermediate descriptors (they are retired by the same event/packet).  
And, yes, SW should probably set the I field on all the descriptors.

David Wooten


"yehiel engel" <YENGEL@HAIFASC3.HAIFA.IBM.COM> Wrote:
| 
| =============================================
| 
| Hello all
| 
| I have a question concerning the interrupt mechanism in
| Buffer Fill mode. As an answer to my previous question,
| Diana said that an interrupt for a descriptor is
| generated only if the descriptor resCount is zero (after
| status update). Suppose that we have a packet that resides
| in 3 (or more) buffer descriptors. After updating the status
| for this packet we should generate interrupt for the first
| descriptor (assuming i field is 2'b11). My question is: should
| we also generate interrupts for the intermediate descriptors
| (descriptors that are not the first and final descriptors for the packet).
| My assumption is that we should not generate interrupt for these
| descriptors. According to this assumption SW should set the i field
| for every descriptor in the context, since it does not have
| a knowledge about the order and the size of the incoming packets.
| If my assumption is wrong, we should save the i field for every
| intermediate descriptor buffer and generate an interrupt (maybe
| more then one) after the status update phase.
| Any comment will be appreciated.
| 
| Regards
| Yehiel Engel
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, April 23, 1997 6:52 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: IRDMA /cycleInconsistent

There is no cycle match on IRDMA.  A cycleInconsistent condition will not 
affect the behavior of IR in any way. 

David Wooten


jyshiuan@sis.com.tw (jyshiuan) Wrote:
| 
| Hi all:
| 
|    I have a question about the IRDMA and cycleInconsistent
| 
|   The OHCI093 said that the ITDMA will be active immediately
|   if a IntEvent.cycleInconsistent condition occures.
| 
|   Will the IRDMA has the same behavior?
|   If we set the cycleMatchEnable for a IRDMA context,
|   and receive a IntEvent.cycleInconsistent condition,
|   Will the IRDMA disable the cycleMatchEnable and become active,
|   or just wait until the contextMatch register matches 
|   the 13-bit cycleCount in the cycleStart packet.
| 
|   Thanks,
| 
| ===============================================
| Jing-Yeh Shiuan
| Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.
| E-mail:     jyshiuan@sis.comp.tw
| Phone:     886-3-5774922 ext 4302
| Fax:          886-3-5790651
| Email:      jyshiuan@sis.com.tw
| Address: No 16, Creation Rd 1, 
|                  Science-based Industrial Park,
|                  Hsin Chu, Taiwan, R. O. C.
| ==============================================
| 
| 
From:	Alan Perry [alanp@pacific.Eng.Sun.COM]
Sent:	Wednesday, April 23, 1997 8:50 AM
To:	1394ohci-l@austin.ibm.com; jyshiuan@sis.com.tw
Subject:	Re: copyRightDataEnable


> Date: Wed, 23 Apr 1997 18:03:55 +0800
> From: jyshiuan@sis.com.tw (jyshiuan)
>
> Hi all:
> 
>    I have a question about the copyRightDataEnable bit in IRDMA contextMatch
> register.
> 
>   In OHCI093, it said, If set, this bit enables the reception of copyrihgt
> Information.
>   what is the "copyrihgt Information"?

You couldn't just say "there is a typo in 0.93", could you? :-)

>   Does this mean that 
>   when this bit is set, then only the packet that "tcode= C" is accepted?

This depends on what happens in the CPTWG Digital Transmission Discussion
Group.  tcode c is only one of the proposals on the table (though a strong
contender).

As it says, the copyRightDataEnable bit enables the reception of copyrighted
information.  It has no effect on non-copyrighted information.

alan perry
From:	John Nels Fuller
Sent:	Wednesday, April 23, 1997 9:27 AM
To:	'Alan Perry'; 1394ohci-l@austin.ibm.com; jyshiuan@sis.com.tw
Subject:	RE: copyRightDataEnable

Assuming that the CPTWG does sanction the tcode 'C' proposal:

Packets with the tcode 4'hC will have the exact same format as
isochronous packets except for the tcode field in the header.  The
intent of copyRightDataEnable is that when the bit is clear then only
normal isochronous packets (tcode 4'hA) may be received for the selected
channel(s) and packets with tcode 4'hC will be treated as if their
channel number did not match (that is, they are ignored by the link).
When copyRightDataEnable is set then either packets with tcode 4'hC or
tcode 4'hA may be received for the selected channel(s).

The link's actions when it sees a tcode 4'hA packet are:
Use channel number field to select an IR context; if none found or if
context is dead or not running then discard packet.

The link's actions when it sees a tcode 4'hC packet are:
Use channel number filed to select an IR context; if none found or if
context is dead or not running or if not copyRightDataEnable then
discard packet.

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> -----Original Message-----
> From:	Alan Perry [SMTP:alanp@pacific.Eng.Sun.COM]
> Sent:	Wednesday, April 23, 1997 8:50 AM
> To:	1394ohci-l@austin.ibm.com; jyshiuan@sis.com.tw
> Subject:	Re: copyRightDataEnable
> 
> 
> > Date: Wed, 23 Apr 1997 18:03:55 +0800
> > From: jyshiuan@sis.com.tw (jyshiuan)
> >
> > Hi all:
> > 
> >    I have a question about the copyRightDataEnable bit in IRDMA
> contextMatch
> > register.
> > 
> >   In OHCI093, it said, If set, this bit enables the reception of
> copyrihgt
> > Information.
> >   what is the "copyrihgt Information"?
> 
> You couldn't just say "there is a typo in 0.93", could you? :-)
> 
> >   Does this mean that 
> >   when this bit is set, then only the packet that "tcode= C" is
> accepted?
> 
> This depends on what happens in the CPTWG Digital Transmission
> Discussion
> Group.  tcode c is only one of the proposals on the table (though a
> strong
> contender).
> 
> As it says, the copyRightDataEnable bit enables the reception of
> copyrighted
> information.  It has no effect on non-copyrighted information.
> 
> alan perry
From:	John Nels Fuller
Sent:	Wednesday, April 23, 1997 1:54 PM
To:	'Jerry Hauck'; 1394ohci-l@austin.ibm.com
Subject:	RE: LinkControl.APhy

It seems to me that this bit turns on the cycle sync messages to the PHY
and also makes the transmit requests grow by a bit for the extra speeds
defined in P1394a.

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> -----Original Message-----
> From:	Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com]
> Sent:	Wednesday, April 16, 1997 10:21 PM
> To:	1394ohci-l@austin.ibm.com
> Subject:	Re: LinkControl.APhy
> 
>      I second Joe's question.  If the bit is set, how does the link
> behave 
>      differently?  What 1394a *link* feature would become active due
> to the 
>      setting of the bit?
>      
>      Conversely, if the bit is not set, how should the link behave?
> Since 
>      not all 1394-1995 PHY's implement the PHY/LINK interface
> consistently, 
>      a single bit can not allow the OHCI link to operate as a
> "universal 
>      link".
>      
>      If universal operation is desired, consistency requires that all
> of 
>      the configuration bits necessary for universal operation would
> have to 
>      be added to the OHCI spec.
>      
>      Alternatively, the OHCI link could simply assume P1394A
> operation.  If 
>      vendor want to implement a universal link, then vendor specific
> bits 
>      could be added independent of the spec.  Since these
> configurations 
>      would have to be set by the BIOS, I don't see that it needs to be
> 
>      standardized or required for all OHCI implementations.
>      
>      I think the only requirement we want is that OHCI compliant
> silicon 
>      MUST work with a P1394a PHY.  Operation with other PHY's is an
> option 
>      of the vendor.
>      
>      Jerry Hauck
>      Intel
>      (408) 765-5528
>      jerry_hauck@ccm.sc.intel.com
> 
> 
> ______________________________ Reply Separator
> _________________________________
> Subject: LinkControl.APhy
> Author:  leew@austin.ibm.com at SMTPGATE
> Date:    4/15/97 9:34 AM
> 
> 
> Question:
>      
> What does this bit tell us?  What sort of action is expected from the
> OHCI 
> controller if this bit is set?
>      
> Joe
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Wednesday, April 23, 1997 3:52 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[2]: LinkControl.APhy


Text item: 



I could see that as a reason, but (1) why would the driver need to toggle it, 
and (2) it seems to me you might want to enable this before the driver is loaded
due to boot devices like disks.

If so, I would not want to turn on the PCI function memory space and locate a 
base address just to toggle this one bit.  I would rather this is done in a 
device specific manner (like PCI config space).

Joe

______________________________ Reply Separator _________________________________
Subject: RE: LinkControl.APhy
Author:  leew@austin.ibm.com at SMTPGATE
Date:    4/23/97 1:53 PM


It seems to me that this bit turns on the cycle sync messages to the PHY 
and also makes the transmit requests grow by a bit for the extra speeds 
defined in P1394a.

_____________________
John Nels Fuller
Software Design Engineer, Windows NT 
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (206) 703-3863
Fax: (206) 93 MSFAX


> -----Original Message-----
> From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
> Sent:     Wednesday, April 16, 1997 10:21 PM
> To:     1394ohci-l@austin.ibm.com
> Subject:     Re: LinkControl.APhy
>
>      I second Joe's question.  If the bit is set, how does the link 
> behave
>      differently?  What 1394a *link* feature would become active due 
> to the
>      setting of the bit?
>
>      Conversely, if the bit is not set, how should the link behave? 
> Since
>      not all 1394-1995 PHY's implement the PHY/LINK interface 
> consistently,
>      a single bit can not allow the OHCI link to operate as a 
> "universal
>      link".
>
>      If universal operation is desired, consistency requires that all 
> of
>      the configuration bits necessary for universal operation would 
> have to
>      be added to the OHCI spec.
>
>      Alternatively, the OHCI link could simply assume P1394A 
> operation.  If
>      vendor want to implement a universal link, then vendor specific 
> bits
>      could be added independent of the spec.  Since these 
> configurations
>      would have to be set by the BIOS, I don't see that it needs to be 
>
>      standardized or required for all OHCI implementations. 
>
>      I think the only requirement we want is that OHCI compliant 
> silicon
>      MUST work with a P1394a PHY.  Operation with other PHY's is an 
> option
>      of the vendor.
>
>      Jerry Hauck
>      Intel
>      (408) 765-5528
>      jerry_hauck@ccm.sc.intel.com
>
>
> ______________________________ Reply Separator 
> _________________________________
> Subject: LinkControl.APhy
> Author:  leew@austin.ibm.com at SMTPGATE 
> Date:    4/15/97 9:34 AM
>
>
> Question:
>
> What does this bit tell us?  What sort of action is expected from the 
> OHCI
> controller if this bit is set?
>
> Joe

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

X-Mailer: Internet Mail Service (5.0.1458.14)
X-Priority: 3
Date: Wed, 23 Apr 1997 13:53:52 -0700
Subject: RE: LinkControl.APhy
To: "'Jerry Hauck'" <Jerry_Hauck@ccm.sc.intel.com>, 1394ohci-l@austin.ibm.com
From: John Nels Fuller <jfuller@MICROSOFT.com>
Message-ID: <F0C5060A8699D011A2B100805F14C8690822BF@RED-75-MSG.dns.microsoft.com
>
Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14)
     id <J38JQ0QW>; Wed, 23 Apr 1997 14:10:14 -0700
Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com [131.107.3.42]) by
 netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id QAA15902 for <1394ohci-l@a
ustin.ibm.com>; Wed, 23 Apr 1997 16:08:43 -0500
Received: from netmail.austin.ibm.com by calliope.fm.intel.com (8.8.4/10.0i); We
d, 23 Apr 1997 21:21:48 GMT
Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) by
fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id OAA14270; Wed, 23 Apr 1997 14:21
:49 -0700 (PDT)
Return-Path: leew@austin.ibm.com
From:	John Nels Fuller
Sent:	Wednesday, April 23, 1997 4:30 PM
To:	'Joseph A Bennett'; 1394ohci-l@austin.ibm.com
Subject:	RE: Re[2]: LinkControl.APhy

As I remember from the P1394a meetings, there are similar bits inside
the PHY to enable the extended features.  The thought being that an "A"
PHY would be able to work with an old link so you had to program the PHY
to turn on its new features and then turn the link's support of those
features on.

I know that our intent is to require "A" PHYs, but we may still need to
play this game to use them.  Note that these things are still under
discussion in P1394a.

> -----Original Message-----
> From:	Joseph A Bennett [SMTP:Joseph_A_Bennett@ccm.fm.intel.com]
> Sent:	Wednesday, April 23, 1997 3:52 PM
> To:	1394ohci-l@austin.ibm.com
> Subject:	Re[2]: LinkControl.APhy
> 
> 
> Text item: 
> 
> 
> 
> I could see that as a reason, but (1) why would the driver need to
> toggle it, 
> and (2) it seems to me you might want to enable this before the driver
> is loaded
> due to boot devices like disks.
> 
> If so, I would not want to turn on the PCI function memory space and
> locate a 
> base address just to toggle this one bit.  I would rather this is done
> in a 
> device specific manner (like PCI config space).
> 
> Joe
> 
> ______________________________ Reply Separator
> _________________________________
> Subject: RE: LinkControl.APhy
> Author:  leew@austin.ibm.com at SMTPGATE
> Date:    4/23/97 1:53 PM
> 
> 
> It seems to me that this bit turns on the cycle sync messages to the
> PHY 
> and also makes the transmit requests grow by a bit for the extra
> speeds 
> defined in P1394a.
> 
> _____________________
> John Nels Fuller
> Software Design Engineer, Windows NT 
> Microsoft Corporation
> One Microsoft Way
> Redmond, WA   98052-6399
> Voice: (206) 703-3863
> Fax: (206) 93 MSFAX
> 
> 
> > -----Original Message-----
> > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
> > Sent:     Wednesday, April 16, 1997 10:21 PM
> > To:     1394ohci-l@austin.ibm.com
> > Subject:     Re: LinkControl.APhy
> >
> >      I second Joe's question.  If the bit is set, how does the link 
> > behave
> >      differently?  What 1394a *link* feature would become active due
> 
> > to the
> >      setting of the bit?
> >
> >      Conversely, if the bit is not set, how should the link behave? 
> > Since
> >      not all 1394-1995 PHY's implement the PHY/LINK interface 
> > consistently,
> >      a single bit can not allow the OHCI link to operate as a 
> > "universal
> >      link".
> >
> >      If universal operation is desired, consistency requires that
> all 
> > of
> >      the configuration bits necessary for universal operation would 
> > have to
> >      be added to the OHCI spec.
> >
> >      Alternatively, the OHCI link could simply assume P1394A 
> > operation.  If
> >      vendor want to implement a universal link, then vendor specific
> 
> > bits
> >      could be added independent of the spec.  Since these 
> > configurations
> >      would have to be set by the BIOS, I don't see that it needs to
> be 
> >
> >      standardized or required for all OHCI implementations. 
> >
> >      I think the only requirement we want is that OHCI compliant 
> > silicon
> >      MUST work with a P1394a PHY.  Operation with other PHY's is an 
> > option
> >      of the vendor.
> >
> >      Jerry Hauck
> >      Intel
> >      (408) 765-5528
> >      jerry_hauck@ccm.sc.intel.com
> >
> >
> > ______________________________ Reply Separator 
> > _________________________________
> > Subject: LinkControl.APhy
> > Author:  leew@austin.ibm.com at SMTPGATE 
> > Date:    4/15/97 9:34 AM
> >
> >
> > Question:
> >
> > What does this bit tell us?  What sort of action is expected from
> the 
> > OHCI
> > controller if this bit is set?
> >
> > Joe
> 
> Text item: External Message Header
> 
> The following mail header is for administrative use
> and may be ignored unless there are problems.
> 
> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
> 
> X-Mailer: Internet Mail Service (5.0.1458.14)
> X-Priority: 3
> Date: Wed, 23 Apr 1997 13:53:52 -0700
> Subject: RE: LinkControl.APhy
> To: "'Jerry Hauck'" <Jerry_Hauck@ccm.sc.intel.com>,
> 1394ohci-l@austin.ibm.com
> From: John Nels Fuller <jfuller@MICROSOFT.com>
> Message-ID:
> <F0C5060A8699D011A2B100805F14C8690822BF@RED-75-MSG.dns.microsoft.com
> >
> Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14)
>      id <J38JQ0QW>; Wed, 23 Apr 1997 14:10:14 -0700
> Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com
> [131.107.3.42]) by
>  netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id QAA15902 for
> <1394ohci-l@a
> ustin.ibm.com>; Wed, 23 Apr 1997 16:08:43 -0500
> Received: from netmail.austin.ibm.com by calliope.fm.intel.com
> (8.8.4/10.0i); We
> d, 23 Apr 1997 21:21:48 GMT
> Received: from calliope.fm.intel.com (calliope.fm.intel.com
> [132.233.247.7]) by
> fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id OAA14270; Wed, 23 Apr
> 1997 14:21
> :49 -0700 (PDT)
> Return-Path: leew@austin.ibm.com
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, April 23, 1997 4:57 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Re[2]: LinkControl.APhy

Joe,

I have no idea why you are making an issue about this bit.  As we have said, 
this is a placeholder and John has provided some examples of how it _might_ be 
used.  If it doesn't get used, then we'll take it out our you can hard wire it 
to 1 in your implementation (assume that there will always be an A PHY 
attached.)  We put it in the link control register because that's where we put 
all the other link related things.

David



Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
| 
| 
| Text item: 
| 
| 
| 
| I could see that as a reason, but (1) why would the driver need to toggle 
it, 
| and (2) it seems to me you might want to enable this before the driver is 
loaded
| due to boot devices like disks.
| 
| If so, I would not want to turn on the PCI function memory space and locate 
a 
| base address just to toggle this one bit.  I would rather this is done in a 
| device specific manner (like PCI config space).
| 
| Joe
| 
| ______________________________ Reply Separator 
_________________________________
| Subject: RE: LinkControl.APhy
| Author:  leew@austin.ibm.com at SMTPGATE
| Date:    4/23/97 1:53 PM
| 
| 
| It seems to me that this bit turns on the cycle sync messages to the PHY 
| and also makes the transmit requests grow by a bit for the extra speeds 
| defined in P1394a.
| 
| _____________________
| John Nels Fuller
| Software Design Engineer, Windows NT 
| Microsoft Corporation
| One Microsoft Way
| Redmond, WA   98052-6399
| Voice: (206) 703-3863
| Fax: (206) 93 MSFAX
| 
| 
| > -----Original Message-----
| > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
| > Sent:     Wednesday, April 16, 1997 10:21 PM
| > To:     1394ohci-l@austin.ibm.com
| > Subject:     Re: LinkControl.APhy
| >
| >      I second Joe's question.  If the bit is set, how does the link 
| > behave
| >      differently?  What 1394a *link* feature would become active due 
| > to the
| >      setting of the bit?
| >
| >      Conversely, if the bit is not set, how should the link behave? 
| > Since
| >      not all 1394-1995 PHY's implement the PHY/LINK interface 
| > consistently,
| >      a single bit can not allow the OHCI link to operate as a 
| > "universal
| >      link".
| >
| >      If universal operation is desired, consistency requires that all 
| > of
| >      the configuration bits necessary for universal operation would 
| > have to
| >      be added to the OHCI spec.
| >
| >      Alternatively, the OHCI link could simply assume P1394A 
| > operation.  If
| >      vendor want to implement a universal link, then vendor specific 
| > bits
| >      could be added independent of the spec.  Since these 
| > configurations
| >      would have to be set by the BIOS, I don't see that it needs to be 
| >
| >      standardized or required for all OHCI implementations. 
| >
| >      I think the only requirement we want is that OHCI compliant 
| > silicon
| >      MUST work with a P1394a PHY.  Operation with other PHY's is an 
| > option
| >      of the vendor.
| >
| >      Jerry Hauck
| >      Intel
| >      (408) 765-5528
| >      jerry_hauck@ccm.sc.intel.com
| >
| >
| > ______________________________ Reply Separator 
| > _________________________________
| > Subject: LinkControl.APhy
| > Author:  leew@austin.ibm.com at SMTPGATE 
| > Date:    4/15/97 9:34 AM
| >
| >
| > Question:
| >
| > What does this bit tell us?  What sort of action is expected from the 
| > OHCI
| > controller if this bit is set?
| >
| > Joe
| 
| Text item: External Message Header
| 
| The following mail header is for administrative use
| and may be ignored unless there are problems.
| 
| ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
| 
| X-Mailer: Internet Mail Service (5.0.1458.14)
| X-Priority: 3
| Date: Wed, 23 Apr 1997 13:53:52 -0700
| Subject: RE: LinkControl.APhy
| To: "'Jerry Hauck'" <Jerry_Hauck@ccm.sc.intel.com>, 
1394ohci-l@austin.ibm.com
| From: John Nels Fuller <jfuller@MICROSOFT.com>
| Message-ID: 
<F0C5060A8699D011A2B100805F14C8690822BF@RED-75-MSG.dns.microsoft.com
| >
| Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14)
|      id <J38JQ0QW>; Wed, 23 Apr 1997 14:10:14 -0700
| Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com 
[131.107.3.42]) by
|  netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id QAA15902 for 
<1394ohci-l@a
| ustin.ibm.com>; Wed, 23 Apr 1997 16:08:43 -0500
| Received: from netmail.austin.ibm.com by calliope.fm.intel.com 
(8.8.4/10.0i); We
| d, 23 Apr 1997 21:21:48 GMT
| Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) 
by
| fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id OAA14270; Wed, 23 Apr 1997 
14:21
| :49 -0700 (PDT)
| Return-Path: leew@austin.ibm.com
| 
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Wednesday, April 23, 1997 5:26 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[4]: LinkControl.APhy


Text item: 


John,

If I hear you right, then, is OHCI controllers may have to do several things if 
they wish to work with the different flavors of 1995 PHYs (such as chipset 
specific bits), but these things would get superceded once the 'APhy' bit is 
set.

My only concern is that the driver is now intimitely involved with setting the 
'A' features.  Has that always been the plan?  I thought the driver would want 
to stay out of this type of configuration.

Joe


______________________________ Reply Separator _________________________________
Subject: RE: Re[2]: LinkControl.APhy
Author:  leew@austin.ibm.com at SMTPGATE
Date:    4/23/97 4:30 PM


As I remember from the P1394a meetings, there are similar bits inside the 
PHY to enable the extended features.  The thought being that an "A" PHY 
would be able to work with an old link so you had to program the PHY to 
turn on its new features and then turn the link's support of those 
features on.

I know that our intent is to require "A" PHYs, but we may still need to 
play this game to use them.  Note that these things are still under 
discussion in P1394a.

> -----Original Message-----
> From:     Joseph A Bennett [SMTP:Joseph_A_Bennett@ccm.fm.intel.com] 
> Sent:     Wednesday, April 23, 1997 3:52 PM
> To:     1394ohci-l@austin.ibm.com
> Subject:     Re[2]: LinkControl.APhy 
>
>
> Text item:
>
>
>
> I could see that as a reason, but (1) why would the driver need to 
> toggle it,
> and (2) it seems to me you might want to enable this before the driver 
> is loaded
> due to boot devices like disks.
>
> If so, I would not want to turn on the PCI function memory space and 
> locate a
> base address just to toggle this one bit.  I would rather this is done 
> in a
> device specific manner (like PCI config space). 
>
> Joe
>
> ______________________________ Reply Separator 
> _________________________________
> Subject: RE: LinkControl.APhy
> Author:  leew@austin.ibm.com at SMTPGATE 
> Date:    4/23/97 1:53 PM
>
>
> It seems to me that this bit turns on the cycle sync messages to the 
> PHY
> and also makes the transmit requests grow by a bit for the extra 
> speeds
> defined in P1394a.
>
> _____________________
> John Nels Fuller
> Software Design Engineer, Windows NT 
> Microsoft Corporation
> One Microsoft Way
> Redmond, WA   98052-6399
> Voice: (206) 703-3863
> Fax: (206) 93 MSFAX
>
>
> > -----Original Message-----
> > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
> > Sent:     Wednesday, April 16, 1997 10:21 PM
> > To:     1394ohci-l@austin.ibm.com 
> > Subject:     Re: LinkControl.APhy 
> >
> >      I second Joe's question.  If the bit is set, how does the link 
> > behave
> >      differently?  What 1394a *link* feature would become active due 
>
> > to the
> >      setting of the bit?
> >
> >      Conversely, if the bit is not set, how should the link behave? 
> > Since
> >      not all 1394-1995 PHY's implement the PHY/LINK interface 
> > consistently,
> >      a single bit can not allow the OHCI link to operate as a 
> > "universal
> >      link".
> >
> >      If universal operation is desired, consistency requires that 
> all
> > of
> >      the configuration bits necessary for universal operation would 
> > have to
> >      be added to the OHCI spec.
> >
> >      Alternatively, the OHCI link could simply assume P1394A 
> > operation.  If
> >      vendor want to implement a universal link, then vendor specific 
>
> > bits
> >      could be added independent of the spec.  Since these 
> > configurations
> >      would have to be set by the BIOS, I don't see that it needs to 
> be
> >
> >      standardized or required for all OHCI implementations. 
> >
> >      I think the only requirement we want is that OHCI compliant 
> > silicon
> >      MUST work with a P1394a PHY.  Operation with other PHY's is an 
> > option
> >      of the vendor.
> >
> >      Jerry Hauck
> >      Intel
> >      (408) 765-5528
> >      jerry_hauck@ccm.sc.intel.com 
> >
> >
> > ______________________________ Reply Separator 
> > _________________________________
> > Subject: LinkControl.APhy
> > Author:  leew@austin.ibm.com at SMTPGATE 
> > Date:    4/15/97 9:34 AM
> >
> >
> > Question:
> >
> > What does this bit tell us?  What sort of action is expected from 
> the
> > OHCI
> > controller if this bit is set?
> >
> > Joe
>
> Text item: External Message Header 
>
> The following mail header is for administrative use 
> and may be ignored unless there are problems.
>
> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. 
>
> X-Mailer: Internet Mail Service (5.0.1458.14) 
> X-Priority: 3
> Date: Wed, 23 Apr 1997 13:53:52 -0700 
> Subject: RE: LinkControl.APhy
> To: "'Jerry Hauck'" <Jerry_Hauck@ccm.sc.intel.com>, 
> 1394ohci-l@austin.ibm.com
> From: John Nels Fuller <jfuller@MICROSOFT.com> 
> Message-ID:
> <F0C5060A8699D011A2B100805F14C8690822BF@RED-75-MSG.dns.microsoft.com 
> >
> Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14) 
>      id <J38JQ0QW>; Wed, 23 Apr 1997 14:10:14 -0700
> Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com 
> [131.107.3.42]) by
>  netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id QAA15902 for 
> <1394ohci-l@a
> ustin.ibm.com>; Wed, 23 Apr 1997 16:08:43 -0500
> Received: from netmail.austin.ibm.com by calliope.fm.intel.com 
> (8.8.4/10.0i); We
> d, 23 Apr 1997 21:21:48 GMT
> Received: from calliope.fm.intel.com (calliope.fm.intel.com 
> [132.233.247.7]) by
> fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id OAA14270; Wed, 23 Apr 
> 1997 14:21
> :49 -0700 (PDT)
> Return-Path: leew@austin.ibm.com

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

X-Mailer: Internet Mail Service (5.0.1458.14)
X-Priority: 3
Date: Wed, 23 Apr 1997 16:30:01 -0700
Subject: RE: Re[2]: LinkControl.APhy
To: "'Joseph A Bennett'" <Joseph_A_Bennett@ccm.fm.intel.com>,
        1394ohci-l@austin.ibm.com
From: John Nels Fuller <jfuller@MICROSOFT.com>
Message-ID: <F0C5060A8699D011A2B100805F14C8690822C3@RED-75-MSG.dns.microsoft.com
>
Received: by INET-04-IMC with Internet Mail Service (5.0.1458.14)
     id <JP00JGSJ>; Wed, 23 Apr 1997 16:34:52 -0700
Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com [131.107.3.29]) by
 netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id SAA149964 for <1394ohci-l@
austin.ibm.com>; Wed, 23 Apr 1997 18:36:47 -0500
Received: from netmail.austin.ibm.com by calliope.fm.intel.com (8.8.4/10.0i); We
d, 23 Apr 1997 23:49:51 GMT
Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) by
fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id QAA02652; Wed, 23 Apr 1997 16:49
:57 -0700 (PDT)
Return-Path: leew@austin.ibm.com
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Wednesday, April 23, 1997 5:33 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[4]: LinkControl.APhy


Text item: 


David,

My only issue with the bit is if there is implied functionality that will occur 
once the bit is set.  If there is to be functionality, I'd like it defined 
sooner rather than later.  If such funcitonality needs to be enabled before a 
driver is loaded, then I don't belive putting in in OHCI space is the right 
thing to do.

My humble experience interfacing with the Microsoft PCI driver has been that if 
it sees the I/O or Memory space enabled in the PCI header (because BIOS enabled 
it) then the driver doesn't want to move it, because it doesn't know if there 
are any dependencies with relocating it.  This, kinda defeats the purpose of 
plug-and-play.

Joe


______________________________ Reply Separator _________________________________
Subject: re: Re[2]: LinkControl.APhy
Author:  leew@austin.ibm.com at SMTPGATE
Date:    4/23/97 6:57 PM


Joe,

I have no idea why you are making an issue about this bit.  As we have said, 
this is a placeholder and John has provided some examples of how it _might_ be 
used.  If it doesn't get used, then we'll take it out our you can hard wire it 
to 1 in your implementation (assume that there will always be an A PHY 
attached.)  We put it in the link control register because that's where we put 
all the other link related things.

David



Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote: 
|
|
| Text item:
|
|
|
| I could see that as a reason, but (1) why would the driver need to toggle 
it,
| and (2) it seems to me you might want to enable this before the driver is 
loaded
| due to boot devices like disks.
|
| If so, I would not want to turn on the PCI function memory space and locate 
a
| base address just to toggle this one bit.  I would rather this is done in a 
| device specific manner (like PCI config space).
|
| Joe
|
| ______________________________ Reply Separator 
_________________________________
| Subject: RE: LinkControl.APhy
| Author:  leew@austin.ibm.com at SMTPGATE 
| Date:    4/23/97 1:53 PM
|
|
| It seems to me that this bit turns on the cycle sync messages to the PHY 
| and also makes the transmit requests grow by a bit for the extra speeds 
| defined in P1394a.
|
| _____________________
| John Nels Fuller
| Software Design Engineer, Windows NT 
| Microsoft Corporation
| One Microsoft Way
| Redmond, WA   98052-6399
| Voice: (206) 703-3863
| Fax: (206) 93 MSFAX
|
|
| > -----Original Message-----
| > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
| > Sent:     Wednesday, April 16, 1997 10:21 PM
| > To:     1394ohci-l@austin.ibm.com 
| > Subject:     Re: LinkControl.APhy 
| >
| >      I second Joe's question.  If the bit is set, how does the link 
| > behave
| >      differently?  What 1394a *link* feature would become active due 
| > to the
| >      setting of the bit?
| >
| >      Conversely, if the bit is not set, how should the link behave? 
| > Since
| >      not all 1394-1995 PHY's implement the PHY/LINK interface 
| > consistently,
| >      a single bit can not allow the OHCI link to operate as a 
| > "universal
| >      link".
| >
| >      If universal operation is desired, consistency requires that all 
| > of
| >      the configuration bits necessary for universal operation would 
| > have to
| >      be added to the OHCI spec.
| >
| >      Alternatively, the OHCI link could simply assume P1394A 
| > operation.  If
| >      vendor want to implement a universal link, then vendor specific 
| > bits
| >      could be added independent of the spec.  Since these 
| > configurations
| >      would have to be set by the BIOS, I don't see that it needs to be 
| >
| >      standardized or required for all OHCI implementations. 
| >
| >      I think the only requirement we want is that OHCI compliant 
| > silicon
| >      MUST work with a P1394a PHY.  Operation with other PHY's is an 
| > option
| >      of the vendor.
| >
| >      Jerry Hauck
| >      Intel
| >      (408) 765-5528
| >      jerry_hauck@ccm.sc.intel.com 
| >
| >
| > ______________________________ Reply Separator 
| > _________________________________
| > Subject: LinkControl.APhy
| > Author:  leew@austin.ibm.com at SMTPGATE 
| > Date:    4/15/97 9:34 AM
| >
| >
| > Question:
| >
| > What does this bit tell us?  What sort of action is expected from the 
| > OHCI
| > controller if this bit is set?
| >
| > Joe
|
| Text item: External Message Header 
|
| The following mail header is for administrative use 
| and may be ignored unless there are problems.
|
| ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. 
|
| X-Mailer: Internet Mail Service (5.0.1458.14) 
| X-Priority: 3
| Date: Wed, 23 Apr 1997 13:53:52 -0700 
| Subject: RE: LinkControl.APhy
| To: "'Jerry Hauck'" <Jerry_Hauck@ccm.sc.intel.com>, 
1394ohci-l@austin.ibm.com
| From: John Nels Fuller <jfuller@MICROSOFT.com> 
| Message-ID:
<F0C5060A8699D011A2B100805F14C8690822BF@RED-75-MSG.dns.microsoft.com 
| >
| Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14) 
|      id <J38JQ0QW>; Wed, 23 Apr 1997 14:10:14 -0700
| Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com 
[131.107.3.42]) by
|  netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id QAA15902 for 
<1394ohci-l@a
| ustin.ibm.com>; Wed, 23 Apr 1997 16:08:43 -0500
| Received: from netmail.austin.ibm.com by calliope.fm.intel.com 
(8.8.4/10.0i); We
| d, 23 Apr 1997 21:21:48 GMT
| Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) 
by
| fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id OAA14270; Wed, 23 Apr 1997 
14:21
| :49 -0700 (PDT)
| Return-Path: leew@austin.ibm.com
|

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: re: Re[2]: LinkControl.APhy
To: <1394ohci-l@austin.ibm.com>
X-Priority: 3 (Normal)
Message-ID: <vines.7Bv7+h,eLnA@bangate.compaq.com>
Date: Wed, 23 Apr 97 18:57:18 CDT
Received: by bangate.compaq.com; Wed, 23 Apr 97 18:57:23 -0500
Received: from bangate.compaq.com(really [131.168.114.234]) by mail.compaq.com
     via sendmail with smtp
     id <m0wKBub-000uHxC@mail.compaq.com>
     for <1394ohci-l@austin.ibm.com>; Wed, 23 Apr 97 18:57:21 -0500 (CDT)
     (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96)
Received: from mail.compaq.com(really [207.18.199.36]) by wotan.compaq.com
     via sendmail with smtp
     id <m0wKBud-00014KC@wotan.compaq.com>
     for <1394ohci-l@austin.ibm.com>; Wed, 23 Apr 1997 18:57:23 -0500 (CDT)
     (Smail-3.2.0.92 1997-Feb-9 #8 built 1997-Apr-10)
From: DavidW@bangate.compaq.com
Received: from wotan.compaq.com (root@wotan.compaq.com [207.18.199.254]) by netm
ail1.austin.ibm.com (8.6.12/8.6.11) with SMTP id SAA53968 for <1394ohci-l@austin
.ibm.com>; Wed, 23 Apr 1997 18:58:27 -0500
Received: from netmail1.austin.ibm.com by calliope.fm.intel.com (8.8.4/10.0i); T
hu, 24 Apr 1997 00:09:15 GMT
Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) by
fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id RAA04656; Wed, 23 Apr 1997 17:09
:15 -0700 (PDT)
Return-Path: leew@austin.ibm.com
From:	John Nels Fuller
Sent:	Wednesday, April 23, 1997 5:59 PM
To:	'Joseph A Bennett'; 1394ohci-l@austin.ibm.com
Subject:	RE: Re[4]: LinkControl.APhy

The intention in P1394a is to define the "A" PHY to be fully backward
compatible with existing 1394-1995 PHYs (that followed Annex J).  That
means that at power-on the link should assume it is talking to an old
PHY and the PHY should assume it is talking to an old link.  Software
will come along and read PHY registers and discover it is an "A" PHY and
turn features on in the PHY registers and then turn features on in the
link to support them [that's the current plan, anyway].

> -----Original Message-----
> From:	Joseph A Bennett [SMTP:Joseph_A_Bennett@ccm.fm.intel.com]
> Sent:	Wednesday, April 23, 1997 5:26 PM
> To:	1394ohci-l@austin.ibm.com
> Subject:	Re[4]: LinkControl.APhy
> 
> 
> Text item: 
> 
> 
> John,
> 
> If I hear you right, then, is OHCI controllers may have to do several
> things if 
> they wish to work with the different flavors of 1995 PHYs (such as
> chipset 
> specific bits), but these things would get superceded once the 'APhy'
> bit is 
> set.
> 
> My only concern is that the driver is now intimitely involved with
> setting the 
> 'A' features.  Has that always been the plan?  I thought the driver
> would want 
> to stay out of this type of configuration.
> 
> Joe
> 
> 
> ______________________________ Reply Separator
> _________________________________
> Subject: RE: Re[2]: LinkControl.APhy
> Author:  leew@austin.ibm.com at SMTPGATE
> Date:    4/23/97 4:30 PM
> 
> 
> As I remember from the P1394a meetings, there are similar bits inside
> the 
> PHY to enable the extended features.  The thought being that an "A"
> PHY 
> would be able to work with an old link so you had to program the PHY
> to 
> turn on its new features and then turn the link's support of those 
> features on.
> 
> I know that our intent is to require "A" PHYs, but we may still need
> to 
> play this game to use them.  Note that these things are still under 
> discussion in P1394a.
> 
> > -----Original Message-----
> > From:     Joseph A Bennett [SMTP:Joseph_A_Bennett@ccm.fm.intel.com] 
> > Sent:     Wednesday, April 23, 1997 3:52 PM
> > To:     1394ohci-l@austin.ibm.com
> > Subject:     Re[2]: LinkControl.APhy 
> >
> >
> > Text item:
> >
> >
> >
> > I could see that as a reason, but (1) why would the driver need to 
> > toggle it,
> > and (2) it seems to me you might want to enable this before the
> driver 
> > is loaded
> > due to boot devices like disks.
> >
> > If so, I would not want to turn on the PCI function memory space and
> 
> > locate a
> > base address just to toggle this one bit.  I would rather this is
> done 
> > in a
> > device specific manner (like PCI config space). 
> >
> > Joe
> >
> > ______________________________ Reply Separator 
> > _________________________________
> > Subject: RE: LinkControl.APhy
> > Author:  leew@austin.ibm.com at SMTPGATE 
> > Date:    4/23/97 1:53 PM
> >
> >
> > It seems to me that this bit turns on the cycle sync messages to the
> 
> > PHY
> > and also makes the transmit requests grow by a bit for the extra 
> > speeds
> > defined in P1394a.
> >
> > _____________________
> > John Nels Fuller
> > Software Design Engineer, Windows NT 
> > Microsoft Corporation
> > One Microsoft Way
> > Redmond, WA   98052-6399
> > Voice: (206) 703-3863
> > Fax: (206) 93 MSFAX
> >
> >
> > > -----Original Message-----
> > > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
> > > Sent:     Wednesday, April 16, 1997 10:21 PM
> > > To:     1394ohci-l@austin.ibm.com 
> > > Subject:     Re: LinkControl.APhy 
> > >
> > >      I second Joe's question.  If the bit is set, how does the
> link 
> > > behave
> > >      differently?  What 1394a *link* feature would become active
> due 
> >
> > > to the
> > >      setting of the bit?
> > >
> > >      Conversely, if the bit is not set, how should the link
> behave? 
> > > Since
> > >      not all 1394-1995 PHY's implement the PHY/LINK interface 
> > > consistently,
> > >      a single bit can not allow the OHCI link to operate as a 

> > > "universal
> > >      link".
> > >
> > >      If universal operation is desired, consistency requires that 
> > all
> > > of
> > >      the configuration bits necessary for universal operation
> would 
> > > have to
> > >      be added to the OHCI spec.
> > >
> > >      Alternatively, the OHCI link could simply assume P1394A 
> > > operation.  If
> > >      vendor want to implement a universal link, then vendor
> specific 
> >
> > > bits
> > >      could be added independent of the spec.  Since these 
> > > configurations
> > >      would have to be set by the BIOS, I don't see that it needs
> to 
> > be
> > >
> > >      standardized or required for all OHCI implementations. 
> > >
> > >      I think the only requirement we want is that OHCI compliant 
> > > silicon
> > >      MUST work with a P1394a PHY.  Operation with other PHY's is
> an 
> > > option
> > >      of the vendor.
> > >
> > >      Jerry Hauck
> > >      Intel
> > >      (408) 765-5528
> > >      jerry_hauck@ccm.sc.intel.com 
> > >
> > >
> > > ______________________________ Reply Separator 
> > > _________________________________
> > > Subject: LinkControl.APhy
> > > Author:  leew@austin.ibm.com at SMTPGATE 
> > > Date:    4/15/97 9:34 AM
> > >
> > >
> > > Question:
> > >
> > > What does this bit tell us?  What sort of action is expected from 
> > the
> > > OHCI
> > > controller if this bit is set?
> > >
> > > Joe
> >
> > Text item: External Message Header 
> >
> > The following mail header is for administrative use 
> > and may be ignored unless there are problems.
> >
> > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. 
> >
> > X-Mailer: Internet Mail Service (5.0.1458.14) 
> > X-Priority: 3
> > Date: Wed, 23 Apr 1997 13:53:52 -0700 
> > Subject: RE: LinkControl.APhy
> > To: "'Jerry Hauck'" <Jerry_Hauck@ccm.sc.intel.com>, 
> > 1394ohci-l@austin.ibm.com
> > From: John Nels Fuller <jfuller@MICROSOFT.com> 
> > Message-ID:
> > <F0C5060A8699D011A2B100805F14C8690822BF@RED-75-MSG.dns.microsoft.com
> 
> > >
> > Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14) 
> >      id <J38JQ0QW>; Wed, 23 Apr 1997 14:10:14 -0700
> > Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com 
> > [131.107.3.42]) by
> >  netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id QAA15902 for 
> > <1394ohci-l@a
> > ustin.ibm.com>; Wed, 23 Apr 1997 16:08:43 -0500
> > Received: from netmail.austin.ibm.com by calliope.fm.intel.com 
> > (8.8.4/10.0i); We
> > d, 23 Apr 1997 21:21:48 GMT
> > Received: from calliope.fm.intel.com (calliope.fm.intel.com 
> > [132.233.247.7]) by
> > fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id OAA14270; Wed, 23
> Apr 
> > 1997 14:21
> > :49 -0700 (PDT)
> > Return-Path: leew@austin.ibm.com
> 
> Text item: External Message Header
> 
> The following mail header is for administrative use
> and may be ignored unless there are problems.
> 
> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
> 
> X-Mailer: Internet Mail Service (5.0.1458.14)
> X-Priority: 3
> Date: Wed, 23 Apr 1997 16:30:01 -0700
> Subject: RE: Re[2]: LinkControl.APhy
> To: "'Joseph A Bennett'" <Joseph_A_Bennett@ccm.fm.intel.com>,
>         1394ohci-l@austin.ibm.com
> From: John Nels Fuller <jfuller@MICROSOFT.com>
> Message-ID:
> <F0C5060A8699D011A2B100805F14C8690822C3@RED-75-MSG.dns.microsoft.com
> >
> Received: by INET-04-IMC with Internet Mail Service (5.0.1458.14)
>      id <JP00JGSJ>; Wed, 23 Apr 1997 16:34:52 -0700
> Received: from INET-04-IMC.microsoft.com (mail4.microsoft.com
> [131.107.3.29]) by
>  netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id SAA149964 for
> <1394ohci-l@
> austin.ibm.com>; Wed, 23 Apr 1997 18:36:47 -0500
> Received: from netmail.austin.ibm.com by calliope.fm.intel.com
> (8.8.4/10.0i); We
> d, 23 Apr 1997 23:49:51 GMT
> Received: from calliope.fm.intel.com (calliope.fm.intel.com
> [132.233.247.7]) by
> fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id QAA02652; Wed, 23 Apr
> 1997 16:49
> :57 -0700 (PDT)
> Return-Path: leew@austin.ibm.com
From:	John Nels Fuller
Sent:	Wednesday, April 23, 1997 6:02 PM
To:	'Joseph A Bennett'; 1394ohci-l@austin.ibm.com
Subject:	RE: Re[4]: LinkControl.APhy

Joe,

Please note that if the boot device is on 1394 it is going to have to be
enabled by BIOS.

jnf

> -----Original Message-----
> From:	Joseph A Bennett [SMTP:Joseph_A_Bennett@ccm.fm.intel.com]
> Sent:	Wednesday, April 23, 1997 5:33 PM
> To:	1394ohci-l@austin.ibm.com
> Subject:	Re[4]: LinkControl.APhy
> 
> 
> Text item: 
> 
> 
> David,
> 
> My only issue with the bit is if there is implied functionality that
> will occur 
> once the bit is set.  If there is to be functionality, I'd like it
> defined 
> sooner rather than later.  If such funcitonality needs to be enabled
> before a 
> driver is loaded, then I don't belive putting in in OHCI space is the
> right 
> thing to do.
> 
> My humble experience interfacing with the Microsoft PCI driver has
> been that if 
> it sees the I/O or Memory space enabled in the PCI header (because
> BIOS enabled 
> it) then the driver doesn't want to move it, because it doesn't know
> if there 
> are any dependencies with relocating it.  This, kinda defeats the
> purpose of 
> plug-and-play.
> 
> Joe
> 
> 
> ______________________________ Reply Separator
> _________________________________
> Subject: re: Re[2]: LinkControl.APhy
> Author:  leew@austin.ibm.com at SMTPGATE
> Date:    4/23/97 6:57 PM
> 
> 
> Joe,
> 
> I have no idea why you are making an issue about this bit.  As we have
> said, 
> this is a placeholder and John has provided some examples of how it
> _might_ be 
> used.  If it doesn't get used, then we'll take it out our you can hard
> wire it 
> to 1 in your implementation (assume that there will always be an A PHY
> 
> attached.)  We put it in the link control register because that's
> where we put 
> all the other link related things.
> 
> David
> 
> 
> 
> Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote: 
> |
> |
> | Text item:
> |
> |
> |
> | I could see that as a reason, but (1) why would the driver need to
> toggle 
> it,
> | and (2) it seems to me you might want to enable this before the
> driver is 
> loaded
> | due to boot devices like disks.
> |
> | If so, I would not want to turn on the PCI function memory space and
> locate 
> a
> | base address just to toggle this one bit.  I would rather this is
> done in a 
> | device specific manner (like PCI config space).
> |
> | Joe
> |
> | ______________________________ Reply Separator 
> _________________________________
> | Subject: RE: LinkControl.APhy
> | Author:  leew@austin.ibm.com at SMTPGATE 
> | Date:    4/23/97 1:53 PM
> |
> |
> | It seems to me that this bit turns on the cycle sync messages to the
> PHY 
> | and also makes the transmit requests grow by a bit for the extra
> speeds 
> | defined in P1394a.
> |
> | _____________________
> | John Nels Fuller
> | Software Design Engineer, Windows NT 
> | Microsoft Corporation
> | One Microsoft Way
> | Redmond, WA   98052-6399
> | Voice: (206) 703-3863
> | Fax: (206) 93 MSFAX
> |
> |
> | > -----Original Message-----
> | > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
> | > Sent:     Wednesday, April 16, 1997 10:21 PM
> | > To:     1394ohci-l@austin.ibm.com 
> | > Subject:     Re: LinkControl.APhy 
> | >
> | >      I second Joe's question.  If the bit is set, how does the
> link 
> | > behave
> | >      differently?  What 1394a *link* feature would become active
> due 
> | > to the
> | >      setting of the bit?
> | >
> | >      Conversely, if the bit is not set, how should the link
> behave? 
> | > Since
> | >      not all 1394-1995 PHY's implement the PHY/LINK interface 
> | > consistently,
> | >      a single bit can not allow the OHCI link to operate as a 
> | > "universal
> | >      link".
> | >
> | >      If universal operation is desired, consistency requires that
> all 
> | > of
> | >      the configuration bits necessary for universal operation
> would 
> | > have to
> | >      be added to the OHCI spec.
> | >
> | >      Alternatively, the OHCI link could simply assume P1394A 
> | > operation.  If
> | >      vendor want to implement a universal link, then vendor
> specific 
> | > bits
> | >      could be added independent of the spec.  Since these 
> | > configurations
> | >      would have to be set by the BIOS, I don't see that it needs
> to be 
> | >
> | >      standardized or required for all OHCI implementations. 
> | >
> | >      I think the only requirement we want is that OHCI compliant 
> | > silicon
> | >      MUST work with a P1394a PHY.  Operation with other PHY's is
> an 
> | > option
> | >      of the vendor.
> | >
> | >      Jerry Hauck
> | >      Intel
> | >      (408) 765-5528
> | >      jerry_hauck@ccm.sc.intel.com 
> | >
> | >
> | > ______________________________ Reply Separator 
> | > _________________________________
> | > Subject: LinkControl.APhy
> | > Author:  leew@austin.ibm.com at SMTPGATE 
> | > Date:    4/15/97 9:34 AM
> | >
> | >
> | > Question:
> | >
> | > What does this bit tell us?  What sort of action is expected from
> the 
> | > OHCI
> | > controller if this bit is set?
> | >
> | > Joe
> |
> | Text item: External Message Header 
> |
> | The following mail header is for administrative use 
> | and may be ignored unless there are problems.
> |
> | ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. 
> |
> | X-Mailer: Internet Mail Service (5.0.1458.14) 
> | X-Priority: 3
> | Date: Wed, 23 Apr 1997 13:53:52 -0700 
> | Subject: RE: LinkControl.APhy
> | To: "'Jerry Hauck'" <Jerry_Hauck@ccm.sc.intel.com>, 
> 1394ohci-l@austin.ibm.com
> | From: John Nels Fuller <jfuller@MICROSOFT.com> 
> | Message-ID:
> <F0C5060A8699D011A2B100805F14C8690822BF@RED-75-MSG.dns.microsoft.com 
> | >
> | Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14) 
> |      id <J38JQ0QW>; Wed, 23 Apr 1997 14:10:14 -0700
> | Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com 
> [131.107.3.42]) by
> |  netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id QAA15902 for 
> <1394ohci-l@a
> | ustin.ibm.com>; Wed, 23 Apr 1997 16:08:43 -0500
> | Received: from netmail.austin.ibm.com by calliope.fm.intel.com 
> (8.8.4/10.0i); We
> | d, 23 Apr 1997 21:21:48 GMT
> | Received: from calliope.fm.intel.com (calliope.fm.intel.com
> [132.233.247.7]) 
> by
> | fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id OAA14270; Wed, 23
> Apr 1997 
> 14:21
> | :49 -0700 (PDT)
> | Return-Path: leew@austin.ibm.com
> |
> 
> Text item: External Message Header
> 
> The following mail header is for administrative use
> and may be ignored unless there are problems.
> 
> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
> 
> Subject: re: Re[2]: LinkControl.APhy
> To: <1394ohci-l@austin.ibm.com>
> X-Priority: 3 (Normal)
> Message-ID: <vines.7Bv7+h,eLnA@bangate.compaq.com>
> Date: Wed, 23 Apr 97 18:57:18 CDT
> Received: by bangate.compaq.com; Wed, 23 Apr 97 18:57:23 -0500
> Received: from bangate.compaq.com(really [131.168.114.234]) by
> mail.compaq.com
>      via sendmail with smtp
>      id <m0wKBub-000uHxC@mail.compaq.com>
>      for <1394ohci-l@austin.ibm.com>; Wed, 23 Apr 97 18:57:21 -0500
> (CDT)
>      (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96)
> Received: from mail.compaq.com(really [207.18.199.36]) by
> wotan.compaq.com
>      via sendmail with smtp
>      id <m0wKBud-00014KC@wotan.compaq.com>
>      for <1394ohci-l@austin.ibm.com>; Wed, 23 Apr 1997 18:57:23 -0500
> (CDT)
>      (Smail-3.2.0.92 1997-Feb-9 #8 built 1997-Apr-10)
> From: DavidW@bangate.compaq.com
> Received: from wotan.compaq.com (root@wotan.compaq.com
> [207.18.199.254]) by netm
> ail1.austin.ibm.com (8.6.12/8.6.11) with SMTP id SAA53968 for
> <1394ohci-l@austin
> .ibm.com>; Wed, 23 Apr 1997 18:58:27 -0500
> Received: from netmail1.austin.ibm.com by calliope.fm.intel.com
> (8.8.4/10.0i); T
> hu, 24 Apr 1997 00:09:15 GMT
> Received: from calliope.fm.intel.com (calliope.fm.intel.com
> [132.233.247.7]) by
> fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id RAA04656; Wed, 23 Apr
> 1997 17:09
> :15 -0700 (PDT)
> Return-Path: leew@austin.ibm.com
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Wednesday, April 23, 1997 7:03 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[6]: LinkControl.APhy


Text item: 



John,

that is my point.  Since BIOS is enabling the devices, it may need (or want) to 
go in and turn on "A" features.  If it is doing that, and the only way to turn 
on an A feature is to enable OHCI memory space, program a base address register,
and set the APhy bit, then it will put the controller in a state that the 
Microsoft PCI driver "won't like".  I put "won't like" in quotes because the 
controller will work (I don't want to imply it will break), but this method goes
against the grain of PCI plug-and-play.

Joe

______________________________ Reply Separator _________________________________
Subject: RE: Re[4]: LinkControl.APhy
Author:  jfuller@MICROSOFT.com at SMTPGATE
Date:    4/23/97 6:02 PM


Joe,

Please note that if the boot device is on 1394 it is going to have to be 
enabled by BIOS.

jnf

> -----Original Message-----
> From:     Joseph A Bennett [SMTP:Joseph_A_Bennett@ccm.fm.intel.com] 
> Sent:     Wednesday, April 23, 1997 5:33 PM
> To:     1394ohci-l@austin.ibm.com
> Subject:     Re[4]: LinkControl.APhy 
>
>
> Text item:
>
>
> David,
>
> My only issue with the bit is if there is implied functionality that 
> will occur
> once the bit is set.  If there is to be functionality, I'd like it 
> defined
> sooner rather than later.  If such funcitonality needs to be enabled 
> before a
> driver is loaded, then I don't belive putting in in OHCI space is the 
> right
> thing to do.
>
> My humble experience interfacing with the Microsoft PCI driver has 
> been that if
> it sees the I/O or Memory space enabled in the PCI header (because 
> BIOS enabled
> it) then the driver doesn't want to move it, because it doesn't know 
> if there
> are any dependencies with relocating it.  This, kinda defeats the 
> purpose of
> plug-and-play.
>
> Joe
>
>
> ______________________________ Reply Separator 
> _________________________________
> Subject: re: Re[2]: LinkControl.APhy
> Author:  leew@austin.ibm.com at SMTPGATE 
> Date:    4/23/97 6:57 PM
>
>
> Joe,
>
> I have no idea why you are making an issue about this bit.  As we have 
> said,
> this is a placeholder and John has provided some examples of how it 
> _might_ be
> used.  If it doesn't get used, then we'll take it out our you can hard 
> wire it
> to 1 in your implementation (assume that there will always be an A PHY 
>
> attached.)  We put it in the link control register because that's 
> where we put
> all the other link related things. 
>
> David
>
>
>
> Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote: 
> |
> |
> | Text item:
> |
> |
> |
> | I could see that as a reason, but (1) why would the driver need to 
> toggle
> it,
> | and (2) it seems to me you might want to enable this before the 
> driver is
> loaded
> | due to boot devices like disks.
> |
> | If so, I would not want to turn on the PCI function memory space and 
> locate
> a
> | base address just to toggle this one bit.  I would rather this is 
> done in a
> | device specific manner (like PCI config space). 
> |
> | Joe
> |
> | ______________________________ Reply Separator 
> _________________________________
> | Subject: RE: LinkControl.APhy
> | Author:  leew@austin.ibm.com at SMTPGATE 
> | Date:    4/23/97 1:53 PM
> |
> |
> | It seems to me that this bit turns on the cycle sync messages to the 
> PHY
> | and also makes the transmit requests grow by a bit for the extra 
> speeds
> | defined in P1394a.
> |
> | _____________________
> | John Nels Fuller
> | Software Design Engineer, Windows NT 
> | Microsoft Corporation
> | One Microsoft Way
> | Redmond, WA   98052-6399
> | Voice: (206) 703-3863
> | Fax: (206) 93 MSFAX
> |
> |
> | > -----Original Message-----
> | > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
> | > Sent:     Wednesday, April 16, 1997 10:21 PM
> | > To:     1394ohci-l@austin.ibm.com 
> | > Subject:     Re: LinkControl.APhy 
> | >
> | >      I second Joe's question.  If the bit is set, how does the 

 link
> | > behave
> | >      differently?  What 1394a *link* feature would become active 
> due
> | > to the
> | >      setting of the bit?
> | >
> | >      Conversely, if the bit is not set, how should the link 
> behave?
> | > Since
> | >      not all 1394-1995 PHY's implement the PHY/LINK interface 
> | > consistently,
> | >      a single bit can not allow the OHCI link to operate as a 
> | > "universal
> | >      link".
> | >
> | >      If universal operation is desired, consistency requires that 
> all
> | > of
> | >      the configuration bits necessary for universal operation 
> would
> | > have to
> | >      be added to the OHCI spec. 
> | >
> | >      Alternatively, the OHCI link could simply assume P1394A 
> | > operation.  If
> | >      vendor want to implement a universal link, then vendor 
> specific
> | > bits
> | >      could be added independent of the spec.  Since these 
> | > configurations
> | >      would have to be set by the BIOS, I don't see that it needs 
> to be
> | >
> | >      standardized or required for all OHCI implementations. 
> | >
> | >      I think the only requirement we want is that OHCI compliant 
> | > silicon
> | >      MUST work with a P1394a PHY.  Operation with other PHY's is 
> an
> | > option
> | >      of the vendor.
> | >
> | >      Jerry Hauck
> | >      Intel
> | >      (408) 765-5528
> | >      jerry_hauck@ccm.sc.intel.com 
> | >
> | >
> | > ______________________________ Reply Separator 
> | > _________________________________
> | > Subject: LinkControl.APhy
> | > Author:  leew@austin.ibm.com at SMTPGATE 
> | > Date:    4/15/97 9:34 AM
> | >
> | >
> | > Question:
> | >
> | > What does this bit tell us?  What sort of action is expected from 
> the
> | > OHCI
> | > controller if this bit is set? 
> | >
> | > Joe
> |
> | Text item: External Message Header 
> |
> | The following mail header is for administrative use 
> | and may be ignored unless there are problems.
> |
> | ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. 
> |
> | X-Mailer: Internet Mail Service (5.0.1458.14) 
> | X-Priority: 3
> | Date: Wed, 23 Apr 1997 13:53:52 -0700 
> | Subject: RE: LinkControl.APhy
> | To: "'Jerry Hauck'" <Jerry_Hauck@ccm.sc.intel.com>, 
> 1394ohci-l@austin.ibm.com
> | From: John Nels Fuller <jfuller@MICROSOFT.com> 
> | Message-ID:
> <F0C5060A8699D011A2B100805F14C8690822BF@RED-75-MSG.dns.microsoft.com 
> | >
> | Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14) 
> |      id <J38JQ0QW>; Wed, 23 Apr 1997 14:10:14 -0700
> | Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com 
> [131.107.3.42]) by
> |  netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id QAA15902 for 
> <1394ohci-l@a
> | ustin.ibm.com>; Wed, 23 Apr 1997 16:08:43 -0500
> | Received: from netmail.austin.ibm.com by calliope.fm.intel.com 
> (8.8.4/10.0i); We
> | d, 23 Apr 1997 21:21:48 GMT
> | Received: from calliope.fm.intel.com (calliope.fm.intel.com 
> [132.233.247.7])
> by
> | fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id OAA14270; Wed, 23 
> Apr 1997
> 14:21
> | :49 -0700 (PDT)
> | Return-Path: leew@austin.ibm.com 
> |
>
> Text item: External Message Header 
>
> The following mail header is for administrative use 
> and may be ignored unless there are problems.
>
> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. 
>
> Subject: re: Re[2]: LinkControl.APhy 
> To: <1394ohci-l@austin.ibm.com>
> X-Priority: 3 (Normal)
> Message-ID: <vines.7Bv7+h,eLnA@bangate.compaq.com> 
> Date: Wed, 23 Apr 97 18:57:18 CDT
> Received: by bangate.compaq.com; Wed, 23 Apr 97 18:57:23 -0500 
> Received: from bangate.compaq.com(really [131.168.114.234]) by 
> mail.compaq.com
>      via sendmail with smtp
>      id <m0wKBub-000uHxC@mail.compaq.com>
>      for <1394ohci-l@austin.ibm.com>; Wed, 23 Apr 97 18:57:21 -0500 
> (CDT)
>      (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96)
> Received: from mail.compaq.com(really [207.18.199.36]) by 
> wotan.compaq.com
>      via sendmail with smtp
>      id <m0wKBud-00014KC@wotan.compaq.com>
>      for <1394ohci-l@austin.ibm.com>; Wed, 23 Apr 1997 18:57:23 -0500 
> (CDT)
>      (Smail-3.2.0.92 1997-Feb-9 #8 built 1997-Apr-10) 
> From: DavidW@bangate.compaq.com
> Received: from wotan.compaq.com (root@wotan.compaq.com 
> [207.18.199.254]) by netm
> ail1.austin.ibm.com (8.6.12/8.6.11) with SMTP id SAA53968 for 
> <1394ohci-l@austin
> .ibm.com>; Wed, 23 Apr 1997 18:58:27 -0500
> Received: from netmail1.austin.ibm.com by calliope.fm.intel.com 
> (8.8.4/10.0i); T
> hu, 24 Apr 1997 00:09:15 GMT
> Received: from calliope.fm.intel.com (calliope.fm.intel.com 
> [132.233.247.7]) by
> fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id RAA04656; Wed, 23 Apr 
> 1997 17:09
> :15 -0700 (PDT)
> Return-Path: leew@austin.ibm.com

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

X-Mailer: Internet Mail Service (5.0.1458.14)
X-Priority: 3
Date: Wed, 23 Apr 1997 18:02:03 -0700
Subject: RE: Re[4]: LinkControl.APhy
To: "'Joseph A Bennett'" <Joseph_A_Bennett@ccm.fm.intel.com>,
        1394ohci-l@austin.ibm.com
From: John Nels Fuller <jfuller@MICROSOFT.com>
Message-ID: <F0C5060A8699D011A2B100805F14C8690822C8@RED-75-MSG.dns.microsoft.com
>
Received: by INET-04-IMC with Internet Mail Service (5.0.1458.14)
     id <JP00JKSB>; Wed, 23 Apr 1997 18:03:57 -0700
Received: from INET-04-IMC.microsoft.com by calliope.fm.intel.com (8.8.4/10.0i);
 Thu, 24 Apr 1997 01:06:07 GMT
Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) by
fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id SAA10310 for <Joseph_A_Bennett@c
cm.fm.intel.com>; Wed, 23 Apr 1997 18:06:10 -0700 (PDT)
Return-Path: jfuller@MICROSOFT.com
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Thursday, April 24, 1997 8:05 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Transmit Read Data Error


Section 13.2.3 (Error section, Transmit Read Data Error) of OHCI 0.93 states:

     If the error (host bus) occurs before a packet's header is placed in 
     the output FIFO, the Host Controller can immediately abort the 
     packet transfer, optionally set the descriptor status to 
     evt_data_read or evt_underrun and move on to the next descriptor 
     block.

Since the packet header is part of the descriptor for all transmit contexts, 
both AT and IT, if an error occurred here, isn't it a descriptor read error?  
I'm wondering if this is a remnant from earlier specs when we didn't require the
packet header to be part of the descriptor block.  Continuing on...

     If, however, the error occurs after the header has been placed in 
     the output FIFO... ...This will cause the Host Controller to send a 
     packet with a length that does not agree with the data_length field 
     of the header.  If the Host Controller receives an ack_data_error 
     from the addressed node, then the Host Controller will substitute 
     evt_data_read or evt_underrun as appropriate.

What is "as appropriate" in the last sentence?  Why not just always put 
evt_data_read if we received an ack_data_error?

Joe
From:	DavidW@bangate.compaq.com
Sent:	Thursday, April 24, 1997 10:56 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Transmit Read Data Error

Joe,

Responses embedded below.

David Wooten


Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
| 
| 
| Section 13.2.3 (Error section, Transmit Read Data Error) of OHCI 0.93 
states:
| 
|      If the error (host bus) occurs before a packet's header is placed in 
|      the output FIFO, the Host Controller can immediately abort the 
|      packet transfer, optionally set the descriptor status to 
|      evt_data_read or evt_underrun and move on to the next descriptor 
|      block.
| 
| Since the packet header is part of the descriptor for all transmit contexts, 

| both AT and IT, if an error occurred here, isn't it a descriptor read error? 
 
| I'm wondering if this is a remnant from earlier specs when we didn't require 
the
| packet header to be part of the descriptor block.  

If the error is a data read error and the header has not yet been moved from 
the descriptor buffer to the output FIFO, then the the status can be updated 
immediately.  For AT, if the header hasn't been put into the output FIFO, then 
the only error that can/should be reported is evt_data_read error since there 
is nothing that could have underrun.  For IT, we could have been late with the 
data in wich case we have either a evt_data_read or an evt_underrun.  If we 
get an underrun on IT, and assuming that we don't lose synchronization with 
the link side, we can do skip processing on the remainder of the IT contexts 
after an underrun.  Else, we let the link force the skip.

| Continuing on...
| 
|      If, however, the error occurs after the header has been placed in 
|      the output FIFO... ...This will cause the Host Controller to send a 
|      packet with a length that does not agree with the data_length field 
|      of the header.  If the Host Controller receives an ack_data_error 
|      from the addressed node, then the Host Controller will substitute 
|      evt_data_read or evt_underrun as appropriate.
| 
| What is "as appropriate" in the last sentence?  Why not just always put 
| evt_data_read if we received an ack_data_error?

We got an ack_data_error because we didn't complete the packet.  The reason 
for not completeing the packet was that we either had a data underrun or we 
had a host bus read error.  The appropriate error to report is the one that 
the HC had that caused the ack_data_error.  The reason for differentiating 
between a data read error from meory or a fifo underrun is that the error 
recovery is significantly different for the two cases (on underrrun we simply 
retry, but for data read error we probably throw our hands up in disgust.)


| 
| Joe
| 
From:	John Nels Fuller
Sent:	Thursday, April 24, 1997 3:06 PM
To:	'Joseph A Bennett'; 1394ohci-l@austin.ibm.com
Subject:	RE: Re[6]: LinkControl.APhy

Joe,

My point is that regardless of the LinkControl.APhy bit the BIOS will
have to enable the OHCI memory space in order to access the boot device
if it is on the 1394 bus.

Also, if everyone does the right job, the A PHY comes up in a mode
compatible with older links and the link comes up in a mode compatible
with older PHYs so that it will just work (without the 1394a features
enabled).  The BIOS in this case would just ignore LinkControl.APhy and
the OS driver would do the work to determine the type of PHY attached.

As a matter of policy, Microsoft does not want any thing in PCI config
space that might have to be touched during the normal operation of a
device.

> -----Original Message-----
> From:	Joseph A Bennett [SMTP:Joseph_A_Bennett@ccm.fm.intel.com]
> Sent:	Wednesday, April 23, 1997 7:03 PM
> To:	1394ohci-l@austin.ibm.com
> Subject:	Re[6]: LinkControl.APhy
> 
> 
> Text item: 
> 
> 
> 
> John,
> 
> that is my point.  Since BIOS is enabling the devices, it may need (or
> want) to 
> go in and turn on "A" features.  If it is doing that, and the only way
> to turn 
> on an A feature is to enable OHCI memory space, program a base address
> register,
> and set the APhy bit, then it will put the controller in a state that
> the 
> Microsoft PCI driver "won't like".  I put "won't like" in quotes
> because the 
> controller will work (I don't want to imply it will break), but this
> method goes
> against the grain of PCI plug-and-play.
> 
> Joe
> 
> ______________________________ Reply Separator
> _________________________________
> Subject: RE: Re[4]: LinkControl.APhy
> Author:  jfuller@MICROSOFT.com at SMTPGATE
> Date:    4/23/97 6:02 PM
> 
> 
> Joe,
> 
> Please note that if the boot device is on 1394 it is going to have to
> be 
> enabled by BIOS.
> 
> jnf
> 
> > -----Original Message-----
> > From:     Joseph A Bennett [SMTP:Joseph_A_Bennett@ccm.fm.intel.com] 
> > Sent:     Wednesday, April 23, 1997 5:33 PM
> > To:     1394ohci-l@austin.ibm.com
> > Subject:     Re[4]: LinkControl.APhy 
> >
> >
> > Text item:
> >
> >
> > David,
> >
> > My only issue with the bit is if there is implied functionality that
> 
> > will occur
> > once the bit is set.  If there is to be functionality, I'd like it 
> > defined
> > sooner rather than later.  If such funcitonality needs to be enabled
> 
> > before a
> > driver is loaded, then I don't belive putting in in OHCI space is
> the 
> > right
> > thing to do.
> >
> > My humble experience interfacing with the Microsoft PCI driver has 
> > been that if
> > it sees the I/O or Memory space enabled in the PCI header (because 
> > BIOS enabled
> > it) then the driver doesn't want to move it, because it doesn't know
> 
> > if there
> > are any dependencies with relocating it.  This, kinda defeats the 
> > purpose of
> > plug-and-play.
> >
> > Joe
> >
> >
> > ______________________________ Reply Separator 
> > _________________________________
> > Subject: re: Re[2]: LinkControl.APhy
> > Author:  leew@austin.ibm.com at SMTPGATE 
> > Date:    4/23/97 6:57 PM
> >
> >
> > Joe,
> >
> > I have no idea why you are making an issue about this bit.  As we
> have 
> > said,
> > this is a placeholder and John has provided some examples of how it 
> > _might_ be
> > used.  If it doesn't get used, then we'll take it out our you can
> hard 
> > wire it
> > to 1 in your implementation (assume that there will always be an A
> PHY 
> >
> > attached.)  We put it in the link control register because that's 
> > where we put
> > all the other link related things. 
> >
> > David
> >
> >
> >
> > Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote: 
> > |
> > |
> > | Text item:
> > |
> > |
> > |
> > | I could see that as a reason, but (1) why would the driver need to
> 
> > toggle
> > it,
> > | and (2) it seems to me you might want to enable this before the 
> > driver is
> > loaded
> > | due to boot devices like disks.
> > |
> > | If so, I would not want to turn on the PCI function memory space
> and 
> > locate
> > a
> > | base address just to toggle this one bit.  I would rather this is 
> > done in a
> > | device specific manner (like PCI config space). 
> > |
> > | Joe
> > |
> > | ______________________________ Reply Separator 
> > _________________________________
> > | Subject: RE: LinkControl.APhy
> > | Author:  leew@austin.ibm.com at SMTPGATE 
> > | Date:    4/23/97 1:53 PM
> > |
> > |
> > | It seems to me that this bit turns on the cycle sync messages to
> the 
> > PHY
> > | and also makes the transmit requests grow by a bit for the extra 
> > speeds
> > | defined in P1394a.
> > |
> > | _____________________
> > | John Nels Fuller
> > | Software Design Engineer, Windows NT 
> > | Microsoft Corporation
> > | One Microsoft Way
> > | Redmond, WA   98052-6399
> > | Voice: (206) 703-3863
> > | Fax: (206) 93 MSFAX
> > |
> > |
> > | > -----Original Message-----
> > | > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
> > | > Sent:     Wednesday, April 16, 1997 10:21 PM
> > | > To:     1394ohci-l@austin.ibm.com 
> > | > Subject:     Re: LinkControl.APhy 
> > | >
> > | >      I second Joe's question.  If the bit is set, how does the 
> > link
> > | > behave
> > | >      differently?  What 1394a *link* feature would become active
> 
> > due
> > | > to the
> > | >      setting of the bit?
> > | >
> > | >      Conversely, if the bit is not set, how should the link 
> > behave?
> > | > Since
> > | >      not all 1394-1995 PHY's implement the PHY/LINK interface 
> > | > consistently,
> > | >      a single bit can not allow the OHCI link to operate as a 
> > | > "universal
> > | >      link".
> > | >
> > | >      If universal operation is desired, consistency requires
> that 
> > all
> > | > of
> > | >      the configuration bits necessary for universal operation 
> > would
> > | > have to
> > | >      be added to the OHCI spec. 
> > | >
> > | >      Alternatively, the OHCI link could simply assume P1394A 
> > | > operation.  If
> > | >      vendor want to implement a universal link, then vendor 
> > specific
> > | > bits
> > | >      could be added independent of the spec.  Since these 
> > | > configurations
> > | >      would have to be set by the BIOS, I don't see that it needs
> 
> > to be
> > | >
> > | >      standardized or required for all OHCI implementations. 
> > | >
> > | >      I think the only requirement we want is that OHCI compliant
> 
> > | > silicon
> > | >      MUST work with a P1394a PHY.  Operation with other PHY's is
> 
> > an
> > | > option
> > | >      of the vendor.
> > | >
> > | >      Jerry Hauck
> > | >      Intel
> > | >      (408) 765-5528
> > | >      jerry_hauck@ccm.sc.intel.com 
> > | >
> > | >
> > | > ______________________________ Reply Separator 
> > | > _________________________________
> > | > Subject: LinkControl.APhy
> > | > Author:  leew@austin.ibm.com at SMTPGATE 
> > | > Date:    4/15/97 9:34 AM
> > | >
> > | >
> > | > Question:
> > | >
> > | > What does this bit tell us?  What sort of action is expected
> from 
> > the
> > | > OHCI
> > | > controller if this bit is set? 
> > | >
> > | > Joe
> > |
> > | Text item: External Message Header 
> > |
> > | The following mail header is for administrative use 
> > | and may be ignored unless there are problems.
> > |
> > | ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. 
> > |
> > | X-Mailer: Internet Mail Service (5.0.1458.14) 
> > | X-Priority: 3
> > | Date: Wed, 23 Apr 1997 13:53:52 -0700 
> > | Subject: RE: LinkControl.APhy
> > | To: "'Jerry Hauck'" <Jerry_Hauck@ccm.sc.intel.com>, 
> > 1394ohci-l@austin.ibm.com
> > | From: John Nels Fuller <jfuller@MICROSOFT.com> 
> > | Message-ID:
> > <F0C5060A8699D011A2B100805F14C8690822BF@RED-75-MSG.dns.microsoft.com
> 
> > | >
> > | Received: by INET-02-IMC with Internet Mail Service (5.0.1458.14) 
> > |      id <J38JQ0QW>; Wed, 23 Apr 1997 14:10:14 -0700
> > | Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com 
> > [131.107.3.42]) by
> > |  netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id QAA15902 for
> 
> > <1394ohci-l@a
> > | ustin.ibm.com>; Wed, 23 Apr 1997 16:08:43 -0500
> > | Received: from netmail.austin.ibm.com by calliope.fm.intel.com 
> > (8.8.4/10.0i); We
> > | d, 23 Apr 1997 21:21:48 GMT
> > | Received: from calliope.fm.intel.com (calliope.fm.intel.com 
> > [132.233.247.7])
> > by
> > | fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id OAA14270; Wed, 23 
> > Apr 1997
> > 14:21
> > | :49 -0700 (PDT)
> > | Return-Path: leew@austin.ibm.com 
> > |
> >
> > Text item: External Message Header 
> >
> > The following mail header is for administrative use 
> > and may be ignored unless there are problems.
> >
> > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. 
> >
> > Subject: re: Re[2]: LinkControl.APhy 
> > To: <1394ohci-l@austin.ibm.com>
> > X-Priority: 3 (Normal)
> > Message-ID: <vines.7Bv7+h,eLnA@bangate.compaq.com> 
> > Date: Wed, 23 Apr 97 18:57:18 CDT
> > Received: by bangate.compaq.com; Wed, 23 Apr 97 18:57:23 -0500 
> > Received: from bangate.compaq.com(really [131.168.114.234]) by 
> > mail.compaq.com
> >      via sendmail with smtp
> >      id <m0wKBub-000uHxC@mail.compaq.com>
> >      for <1394ohci-l@austin.ibm.com>; Wed, 23 Apr 97 18:57:21 -0500 
> > (CDT)
> >      (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96)
> > Received: from mail.compaq.com(really [207.18.199.36]) by 
> > wotan.compaq.com
> >      via sendmail with smtp
> >      id <m0wKBud-00014KC@wotan.compaq.com>
> >      for <1394ohci-l@austin.ibm.com>; Wed, 23 Apr 1997 18:57:23
> -0500 
> > (CDT)
> >      (Smail-3.2.0.92 1997-Feb-9 #8 built 1997-Apr-10) 
> > From: DavidW@bangate.compaq.com
> > Received: from wotan.compaq.com (root@wotan.compaq.com 
> > [207.18.199.254]) by netm
> > ail1.austin.ibm.com (8.6.12/8.6.11) with SMTP id SAA53968 for 
> > <1394ohci-l@austin
> > .ibm.com>; Wed, 23 Apr 1997 18:58:27 -0500
> > Received: from netmail1.austin.ibm.com by calliope.fm.intel.com 
> > (8.8.4/10.0i); T
> > hu, 24 Apr 1997 00:09:15 GMT
> > Received: from calliope.fm.intel.com (calliope.fm.intel.com 
> > [132.233.247.7]) by
> > fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id RAA04656; Wed, 23
> Apr 
> > 1997 17:09
> > :15 -0700 (PDT)
> > Return-Path: leew@austin.ibm.com
> 
> Text item: External Message Header
> 
> The following mail header is for administrative use
> and may be ignored unless there are problems.
> 
> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
> 
> X-Mailer: Internet Mail Service (5.0.1458.14)
> X-Priority: 3
> Date: Wed, 23 Apr 1997 18:02:03 -0700
> Subject: RE: Re[4]: LinkControl.APhy
> To: "'Joseph A Bennett'" <Joseph_A_Bennett@ccm.fm.intel.com>,
>         1394ohci-l@austin.ibm.com
> From: John Nels Fuller <jfuller@MICROSOFT.com>
> Message-ID:
> <F0C5060A8699D011A2B100805F14C8690822C8@RED-75-MSG.dns.microsoft.com
> >
> Received: by INET-04-IMC with Internet Mail Service (5.0.1458.14)
>      id <JP00JKSB>; Wed, 23 Apr 1997 18:03:57 -0700
> Received: from INET-04-IMC.microsoft.com by calliope.fm.intel.com
> (8.8.4/10.0i);
>  Thu, 24 Apr 1997 01:06:07 GMT
> Received: from calliope.fm.intel.com (calliope.fm.intel.com
> [132.233.247.7]) by
> fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id SAA10310 for
> <Joseph_A_Bennett@c
> cm.fm.intel.com>; Wed, 23 Apr 1997 18:06:10 -0700 (PDT)
> Return-Path: jfuller@MICROSOFT.com
From:	cylin@sis.com.tw
Sent:	Thursday, April 24, 1997 7:23 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: run clear interrupt

Hi,

Let me clarify the point. Before SW clears run, active could be cleared
because of a dead condition, bus reset, or Z=0 of a descriptor indicating
a branch. If, before SW clears run, one of the above conditions occurs,
should HW issued this interrupt?- Since SW could be notified of the
above conditions by their corresponding interrupt. However, it is possible
that SW will be polling this run cleared interrupt after it clears run. 
OHCI0.93 stated that "When ContextControl.active is cleared and 
ContextControl.run is already cleared,the Host Controller will set the
IntEvent bit for the context", but the situation described here is 
different: "When ContextControl.run is cleared and ContextControl.active 
is already cleared". If SW always expect this interrupt no matter active 
is cleared before or after run is cleared, then it will be clearer to 
append the situation described here to the 2nd para. Sec. 3.1.1.3. 

Thanks,

C.Y.

>I really don't understand the question here.  What "other reasons" are you 
>talking about?
>
>David Wooten
>
>
>cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
>| 
>| Hi,
>| 
>| I have a question about the interrupt issued for run clear:
>| OHCI0.92, Sec.3.1.1.3, 2nd para., said "When ContextControl.active is 
>| cleared and ContextControl.run is already clear, the Host Controller will
>| set the IntEvent bit for the context". My question is, if active is
>| cleared for some other reasons before run is cleared, does SW exepect
>| this interrupt?
>| 
>| Thanks for your time and answers,
>| 
>| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>| Chien-Yuh Lin
>| Design Engineer
>| Basic Technology Group
>| Silicon Intergrated Systems Corp.
>| Tel: 886-3-5774922 x 4326
>| Fax: 886-3-5778774
>| Email: cylin@sis.com.tw
>| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>| 
>| 
>
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	jyshiuan@sis.com.tw
Sent:	Friday, April 25, 1997 1:39 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Vendor ID register

Hi all:

  I have a question about the Vendor ID register.
  
  In OpenHCI 093, p36, it said:

  The company ID of the organization that specified the pacticular
  set of vendor unique registers and behaviors of this particular 
  implementation of the 1394 Open HCI. If no additional features 
  are implemented, this field shall be 24'h0.

  My question is that if we have obtained a company ID from IEEE,
  would we implement the company ID in this register?
  or just set this field to 24'h0?

  Will there be any SW issue to read this field?

  Thanks

===============================================
Jing-Yeh Shiuan
Engineer
Basic Technology Group
Silicon Integrated Systems Corp.
E-mail:     jyshiuan@sis.comp.tw
Phone:     886-3-5774922 ext 4302
Fax:          886-3-5790651
Email:      jyshiuan@sis.com.tw
Address: No 16, Creation Rd 1, 
                 Science-based Industrial Park,
                 Hsin Chu, Taiwan, R. O. C.
==============================================
From:	DavidW@bangate.compaq.com
Sent:	Friday, April 25, 1997 7:51 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: run clear interrupt

I don't think we intended for there to be an interrupt if active were cleared 
before run was cleared.  SW can detect this by looking at active after run is 
set. The reason for having the interrupt when active is cleared as a result of 
run being cleared is that the HC may take some time before active is cleared.  
Rather than have SW wait around, we have an interrupt that indicates that the 
HC has completely stopped the context.

So, answer to your question, as modified and clarified, is no.  Interrupt is 
not generated if active is cleared before run is cleared.

David

cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| 
| Hi,
| 
| Let me clarify the point. Before SW clears run, active could be cleared
| because of a dead condition, bus reset, or Z=0 of a descriptor indicating
| a branch. If, before SW clears run, one of the above conditions occurs,
| should HW issued this interrupt?- Since SW could be notified of the
| above conditions by their corresponding interrupt. However, it is possible
| that SW will be polling this run cleared interrupt after it clears run. 
| OHCI0.93 stated that "When ContextControl.active is cleared and 
| ContextControl.run is already cleared,the Host Controller will set the
| IntEvent bit for the context", but the situation described here is 
| different: "When ContextControl.run is cleared and ContextControl.active 
| is already cleared". If SW always expect this interrupt no matter active 
| is cleared before or after run is cleared, then it will be clearer to 
| append the situation described here to the 2nd para. Sec. 3.1.1.3. 
| 
| Thanks,
| 
| C.Y.
| 
| >I really don't understand the question here.  What "other reasons" are you 
| >talking about?
| >
| >David Wooten
| >
| >
| >cylin@sis.com.tw (Chien-Yuh Lin) Wrote:
| >| 
| >| Hi,
| >| 
| >| I have a question about the interrupt issued for run clear:
| >| OHCI0.92, Sec.3.1.1.3, 2nd para., said "When ContextControl.active is 
| >| cleared and ContextControl.run is already clear, the Host Controller will
| >| set the IntEvent bit for the context". My question is, if active is
| >| cleared for some other reasons before run is cleared, does SW exepect
| >| this interrupt?
| >| 
| >| Thanks for your time and answers,
| >| 
| >| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| >| Chien-Yuh Lin
| >| Design Engineer
| >| Basic Technology Group
| >| Silicon Intergrated Systems Corp.
| >| Tel: 886-3-5774922 x 4326
| >| Fax: 886-3-5778774
| >| Email: cylin@sis.com.tw
| >| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| >| 
| >| 
| >
| >
| 
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Chien-Yuh Lin
| Design Engineer
| Basic Technology Group
| Silicon Intergrated Systems Corp.
| Tel: 886-3-5774922 x 4326
| Fax: 886-3-5778774
| Email: cylin@sis.com.tw
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, April 25, 1997 8:04 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Vendor ID register

This answer contains opinions about how OS's select drivers to associate with 
devices.  I'd like Eric and John and Diana to check my answer and complain if 
I got it wrong.

If your implementation has no vendor unique features, then use 24'h0.  That 
tells SW that it should use the generic driver.  Else, you need to put in the 
vendor ID (OUI as obtained from the IEEE) of the company that defines the 
vendor unique features.

You may put your vendor ID in this field if you like whether or not you have 
any vendor unique features.  If a vendor unique driver can't be found, the the 
OS should connect the generic OHCI driver.  This should always work since all 
implementations must be compliant with the OCHI specification but they may 
have extended capabilities.

Was that answer confusing enough?

David Wooten


jyshiuan@sis.com.tw (jyshiuan) Wrote:
| 
| Hi all:
| 
|   I have a question about the Vendor ID register.
|   
|   In OpenHCI 093, p36, it said:
| 
|   The company ID of the organization that specified the pacticular
|   set of vendor unique registers and behaviors of this particular 
|   implementation of the 1394 Open HCI. If no additional features 
|   are implemented, this field shall be 24'h0.
| 
|   My question is that if we have obtained a company ID from IEEE,
|   would we implement the company ID in this register?
|   or just set this field to 24'h0?
| 
|   Will there be any SW issue to read this field?
| 
|   Thanks
| 
| ===============================================
| Jing-Yeh Shiuan
| Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.
| E-mail:     jyshiuan@sis.comp.tw
| Phone:     886-3-5774922 ext 4302
| Fax:          886-3-5790651
| Email:      jyshiuan@sis.com.tw
| Address: No 16, Creation Rd 1, 
|                  Science-based Industrial Park,
|                  Hsin Chu, Taiwan, R. O. C.
| ==============================================
| 
| 
From:	DavidW@bangate.compaq.com
Sent:	Friday, April 25, 1997 4:30 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: IRDMA /cycleInconsistent

While IntEvent.cycleInconsistent is set, _all_ cycle matching is disabled IR 
and IT.  Things that were started as a result of matching a cycle number will 
continue to run but contexts that are still waiting for a cycle match will not 
start while cycleInconsistent is set.  For both IR and IT cycleMatchEnable is 
not turned off when cycleInsonsistent is set.  Rather, matching is inhibited.  
If cycleMatchEnable were turned off in the context, then the context would 
start running and that clearly is not the behavior that is desired.

David

jyshiuan@sis.com.tw (jyshiuan) Wrote:
| 
| Hi David:
| 
|   I think that maybe you misunderstood my question.
|   There is a bit "cycleMatchEnable" on Conext Control register.
|   And the "cycleMatch" field is on Contect Match register.
|   
|    My question is that:
|    If a cycleInconsistent condition occurs,
|    will the IRDMA disable the cycleMatchEnable and become active.
|    or still wait until the cycleMatch filed match the 13-bit cycleCount in
| the cycleStart packet.
| 
| 
|   The second question is about IT DMA in OHCI v0.93,page 100, section 9.5.1 
:
| 
| It describes that "When the IntEvent.cycleInconsistent condition 
| occurs,the IT DMA controller shall continue processing running contexts 
| normally,.........". If the link side cycle timer has been changed by 
| software in the cycle master node, how should the host side cycle timer be 
| changed in the cycle master node ? Since according to OHCI v0.93,page 
| 47,Table 6-1, the cycleInconsistent interrupt event is reported only when 
| cycle start was received,thus the cycle master node won't report 
| cycleInconsistent event when software modifies the link side cycle timer. Or 

| cycle master node need to report cycleInconsistent event in such a case.
| 
|   Thanks.
| 
| >There is no cycle match on IRDMA.  A cycleInconsistent condition will not 
| >affect the behavior of IR in any way. 
| >
| >David Wooten
| >
| >
| >jyshiuan@sis.com.tw (jyshiuan) Wrote:
| >| 
| >| Hi all:
| >| 
| >|    I have a question about the IRDMA and cycleInconsistent
| >| 
| >|   The OHCI093 said that the ITDMA will be active immediately
| >|   if a IntEvent.cycleInconsistent condition occures.
| >| 
| >|   Will the IRDMA has the same behavior?
| >|   If we set the cycleMatchEnable for a IRDMA context,
| >|   and receive a IntEvent.cycleInconsistent condition,
| >|   Will the IRDMA disable the cycleMatchEnable and become active,
| >|   or just wait until the contextMatch register matches 
| >|   the 13-bit cycleCount in the cycleStart packet.
| >| 
| >|   Thanks,
| >| 
| >| ===============================================
| >| Jing-Yeh Shiuan
| >| Engineer
| >| Basic Technology Group
| >| Silicon Integrated Systems Corp.
| >| E-mail:     jyshiuan@sis.comp.tw
| >| Phone:     886-3-5774922 ext 4302
| >| Fax:          886-3-5790651
| >| Email:      jyshiuan@sis.com.tw
| >| Address: No 16, Creation Rd 1, 
| >|                  Science-based Industrial Park,
| >|                  Hsin Chu, Taiwan, R. O. C.
| >| ==============================================
| >| 
| >| 
| >
| >
| >
| 
| ===============================================
| Jing-Yeh Shiuan
| Engineer
| Basic Technology Group
| Silicon Integrated Systems Corp.
| E-mail:     jyshiuan@sis.comp.tw
| Phone:     886-3-5774922 ext 4302
| Fax:          886-3-5790651
| Email:      jyshiuan@sis.com.tw
| Address: No 16, Creation Rd 1, 
|                  Science-based Industrial Park,
|                  Hsin Chu, Taiwan, R. O. C.
| ==============================================
| 
| 
From:	cmlin@sis.com.tw
Sent:	Monday, April 28, 1997 8:27 AM
To:	1394ohci-l@austin.ibm.com
Subject:	A question about ITDMA tcode error

Hi all,

I have a question about ITDMA tcode error.

  There is no tcode error event for ITDMA in OHCI 0.93.
However, in slide 35 for the meeting held on December,
18-19, 1996, it described as follows for ITDMA tcode
error:
* Means that tCode not appropriate for context (not iso
   tCode)
* tCode error also means that header length doesn't match
   tCode
* Don't put header into output FIFO -- don't start packet.
* Set ContextControl.ack to evt_tcode_err
* Conditionally save ContextControl in xferStatus of 
   OUTPUT_LAST* and conditionally generate interrupt  

  Are the above descriptions still correct?  If yes, should the
OHCI0.93 add the evt_tcode_err for ITDMA?  If no, how
should we do in the above case?
  
Thanks for your time and answer,


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chi-Ming Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4324
Fax: 886-3-5790651
Email: cmlin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	daisy@sis.com.tw
Sent:	Monday, April 28, 1997 12:27 AM
To:	1394ohci-l@austin.ibm.com; daisy@sis.com.tw
Subject:	IT underrun

Hi, all,

I have a question about IT underrun,

Suppose there are 4 Iso packets needed to be transmitted in each Iso cycle,
say, if there is no underrun occurs, then
     cycle 1 : A1 B1 C1 D1
     cycle 2 : A2 B2 C2 D2
    
if underrun occurs in B1, it could happen that C1/D1 still have a chance to 
be transmitted in cycle 1 if the Iso period does not end and we won the 
arbition. Should host controller go to arbitrate the bus in cycle 1 if
C1/D1 is ready for transmission ? or should host controller give up the bus 
and transmit C1/D1 in cycle 2 ?
 
Thanks for your time and answer,

Y.J. Chao
====================================
Yen-Jiuan Chao (Daisy)
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp.(SiS)
Phone  : 886-3-5774922 ext. 4315
Fax    : 886-3-5790651
E-mail : daisy@sis.com.tw
=====================================
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Monday, April 28, 1997 4:51 PM
To:	1394ohci-l@austin.ibm.com
Subject:	ContextControl.wake

---------------------------- Forwarded with Changes ---------------------------
From: Joseph A Bennett at FMCCM4
Date: 4/28/97 4:35PM
To: Mikal Hunsaker at FMCCM4
Subject: ContextControl.wake
-------------------------------------------------------------------------------


On page 16 of OHCI 0.93, paragraph 1, where it is describing the wake bit, OHCI 
states:

    "...Therefore, if the Host Controller had fetched a descriptor and the 
    indicated branch address had a Z value of zero, then the Host Controller 
    should reread the pointer value.  If, on the reread, the Z value is still 
    zero, then the end of the list has been reached and the Host Controller 
    should clear ContextControl.active.  If, however, the Z value is now 
    non-zero, the Host Controller will continue processing."

This seems to work very well for transmit contexts.  However, take the case of 
receive contexts in buffer-fill mode.  If a packet is coming into one of these 
contexts, the Host Controller is on a descriptor block whose Z-value is zero, 
AND it does not have buffer room (the data coming in exceeds resCount), AND on a
re-read of the descriptor, the Z-value is STILL 0, then the Host Controller is 
going to reject the packet, correct?

If so, then there is still room in the buffer, so there is no need for the 
context to go inactive.

If all this holds true, does 'going inactive' on receive contexts make much 
sense?  If this doesn't hold true, does this mean receive contexts should go 
inactive if they happen to get a request/response/isoch data whose length is 
greater than resCount and Z is '0'?

Joe
From:	DavidW@bangate.compaq.com
Sent:	Tuesday, April 29, 1997 9:39 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: ContextControl.wake

Joe,

First, remember that the reread is triggered because wake is active.  Wake was 
cleared before we read the descriptor the first time.  This means that if wake 
is set after we have fetched a descriptor, then SW most likely would have 
added to the list.  So, when we have Z=0 from a previous read and wake is 
active, a reread of the descriptor should almost never (can't trust SW all 
that much) have Z=0.

Now, assuming that we have hit Z=0 on a buffer fill context, it doesn't much 
matter if we have a wake or not.  If we have run out of buffer space we are 
out of space.  For AR contexts, we have decided that we are going to keep the 
context alive even when we try to write a packet that doesn't fit.  Notion is 
that SW is trying to keep AR alive and is going to hit wake as soon as 
possible with another buffer.  Continuing to take the packets that will fit in 
the remaining space prevents those packets from being retried latter (that 
wasn't very clear but bottom line is that it is marginally better not to stop 
AR simply because buffer fills (we will stop if buffer fills exactly and Z=0 
but that is rare.)

Just like there is no particular benefit to stop the AR context when the 
buffer is full, there is no clear benefit, that I can see, of stopping the IR 
context when a packet doesn't fit.  In particular, we wouldn't want a context 
in multi-mode to stop when a packet doesn't fit because we might still be able 
to receive packet from other channels.  If we don't stop multi-mode, and we 
don't stop AR, why should we make an exception for IR when it is not in 
multi-mode?

As is obvious from this reply, I have not had my daily dose of caffeine so my 
response is not all that coherent.  I guess I could have waited until latter 
in the day to reply but then I wouldn't have this excuse for an incoherent 
reply and I'm not sure that I'll actually be able to do any better.  So, this 
is what you get...

David Wooten

Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
| 
| ---------------------------- Forwarded with Changes 
---------------------------
| From: Joseph A Bennett at FMCCM4
| Date: 4/28/97 4:35PM
| To: Mikal Hunsaker at FMCCM4
| Subject: ContextControl.wake
| 
------------------------------------------------------------------------------
-
| 
| 
| On page 16 of OHCI 0.93, paragraph 1, where it is describing the wake bit, 
OHCI 
| states:
| 
|     "...Therefore, if the Host Controller had fetched a descriptor and the 
|     indicated branch address had a Z value of zero, then the Host Controller 

|     should reread the pointer value.  If, on the reread, the Z value is 
still 
|     zero, then the end of the list has been reached and the Host Controller 
|     should clear ContextControl.active.  If, however, the Z value is now 
|     non-zero, the Host Controller will continue processing."
| 
| This seems to work very well for transmit contexts.  However, take the case 
of 
| receive contexts in buffer-fill mode.  If a packet is coming into one of 
these 
| contexts, the Host Controller is on a descriptor block whose Z-value is 
zero, 
| AND it does not have buffer room (the data coming in exceeds resCount), AND 
on a
| re-read of the descriptor, the Z-value is STILL 0, then the Host Controller 
is 
| going to reject the packet, correct?
| 
| If so, then there is still room in the buffer, so there is no need for the 
| context to go inactive.
| 
| If all this holds true, does 'going inactive' on receive contexts make much 
| sense?  If this doesn't hold true, does this mean receive contexts should go 

| inactive if they happen to get a request/response/isoch data whose length is 

| greater than resCount and Z is '0'?
| 
| Joe
| 
From:	Madhsudan Hans [hansm@madmats.esd.sgi.com]
Sent:	Tuesday, April 29, 1997 10:40 AM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe?

Sorry for the wide distribution, but could somebody tell me how I can
subscribe to the 1394ohci mailing list. I could not find it on the list of
reflectors on the 1394ta website.

Also, is there an archive of all postings to this reflector?

Thanks.

-- 
Madhsudan Hans
Silicon Graphics, Inc
Mountain View CA
hansm@sgi.com
From:	l.damico@neccsd.com
Sent:	Monday, April 28, 1997 4:17 PM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

     subscribe
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Thursday, May 01, 1997 9:45 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Annex B clarifications


OHCI seems a little unclear in some areas of Annex B (PCI annex):

Section B.2, Busmastering Requirements
     If the bus master enable bit is cleared in the PCI config space, the 
     PCI logic must 'kill' all DMA contexts.  Does this mean that hardware 
     is clearing the run bit for all contexts?  I don't think this is 
     necessary.  This is a very drastic thing to do, and I think software 
     should actually kill the contexts.  There should also be a restriction 
     on software that if the bus master bit is cleared, software must clear 
     the run bits and wait for all active bits to go to zero before 
     re-enabling the bus master bit.
     
     OHCI hardware on PCI should just stop running PCI master cycles on 
     behalf of DMA contexts if this bit is cleared.

Section B.3.1, Command Register
     The paragraph refers to the MA and BM fields.  I assume 'BM' is the 
     bus master bit, but what is 'MA'?  I assume we mean the memory space 
     enable bit.  Better wording in this paragraph would be nice.
     
     In addition, all of the bits in the command register are listed as 
     read/write.  Many of these bits are not implemented.  The PCI spec 
     states that unimplemented bits do not need to be read/write.
 
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Thursday, May 01, 1997 12:13 PM
To:	1394ohci-l@austin.ibm.com
Subject:	No need to back-out when ack not delivered

     A change in OHCI 0.93 to section "8.4.2.2 Error Handling" includes the 
     following paragraph pertaining to the AR DMA:
     
        Similarly, if a bus reset occurs after a packet has been 
        received but before the ack is sent, the packet will be 
        "backed-out" of the buffer(s) as described for ack_data_error 
        above.
     
     I recall a reflector discussion from two months ago (between Yehuda 
     Peled and David Wooten) which may have prompted this addition to 
     0.93.  The thread is included at the end of this message.
     
     However, I do not agree that the above is required or desired 
     behavior.  If the packet (for which the ack was aborted) was to be 
     dispatched to the AR Request DMA, then it will be flushed by software 
     as a result of the bus reset.  No harm in leaving the packet in the 
     buffer with the ack code intended to be sent.  Software can still 
     parse the buffer and ignore the packet as usual.
     
     If the packet was to be dispatched to the AR Response DMA, then enough 
     of the response was received for software to retire the associated 
     transaction before acting on the bus reset.  The responder takes the 
     same action whether an ack is received or not.  (A responder can never 
     retry a response for which no ack was received ... it is impossible to 
     know whether it was the response or the ack which was lost.)  Since it 
     makes no difference to the responder, I don't understand why we would 
     require OHCI to throw away a perfectly valid response?
     
     Consequently, I request that the requirement to back-out the packet be 
     removed (or backed-out) from the OHCI spec.  Implementations are free 
     to either return the ack code intended to be sent by the link or back 
     the packet out, with a preference for the former.
     
     Regards,
     
     Jerry Hauck
     Intel Corporation
     jerry_hauck@ccm.sc.intel.com
     (408) 765-5528


| Yehuda,
|
| Yes.  Back the packet out.
|
| David
|
|
| "Yehuda Peled (972-4-8296149)" <ypeled@VNET.IBM.COM> Wrote: 
| |
| | David,
| | Thanks for your response.
| | I agree with your analysis.
| | In our implementation, the HC will not write any status if the packet 
| | was not sent.
| | By the way, in the AR side, if there is a bus reset after the packet
| | end and before we send an acknowledge, then the packet should be backed 
| | out ?
| |
| | Thanks
| |  Yehuda
| |
|
From:	Carl.Humphreys@East.Sun.COM
Sent:	Thursday, May 01, 1997 8:53 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Physical write error related question



In a situation where a physical write request is received - which 
has not been posted - (but has been acknowledged with an ack_pending) 
has been successfully written into the FIFO but while transmitting to
host memory a bus error occurs, I believe a response with rcode of 
resp_data_error must be sent to the requesting node.

My question is this.  Is it expected that the hardware unload the 
remaining packet in the FIFO and skip down to find the trailer quadlet 
to obtain the 'spd' field of the originating write request - and respond 
at that same 'spd'?  (Or is a response at the base rate spd acceptable
given this situation to possibly prepare a concatenated response?)

- ie: as soon as the memory write error is seen, the response packet
is scheduled without having to wait to find the trailer quadlet.


Thanks,

- Carl
From:	Carl.Humphreys@East.Sun.COM
Sent:	Thursday, May 01, 1997 9:05 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Physical write error related question



Thinking about the concatenation rules... unless the write request
was at S100 anyway, concatenation of the base rate response wouldn't be
allowed. 

In that case, it seems that you would need to find out the speed of the 
write request that resulted in the error anyway.  If this is not true, 
let me know.

- Carl


----- Begin Included Message -----

From carlh Thu May  1 23:52:57 1997
To: 1394ohci-l@austin.ibm.com
Subject: Physical write error related question



In a situation where a physical write request is received - which 
has not been posted - (but has been acknowledged with an ack_pending) 
has been successfully written into the FIFO but while transmitting to
host memory a bus error occurs, I believe a response with rcode of 
resp_data_error must be sent to the requesting node.

My question is this.  Is it expected that the hardware unload the 
remaining packet in the FIFO and skip down to find the trailer quadlet 
to obtain the 'spd' field of the originating write request - and respond 
at that same 'spd'?  (Or is a response at the base rate spd acceptable
given this situation to possibly prepare a concatenated response?)

- ie: as soon as the memory write error is seen, the response packet
is scheduled without having to wait to find the trailer quadlet.


Thanks,

- Carl


----- End Included Message -----
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Friday, May 02, 1997 7:43 AM
To:	1394ohci-l@austin.ibm.com
Subject:	PhyControl register


I have made the following assumptions about the PHY Control register when 
transmitting read register and write register requests.  Is this a correct 
interpretation?

When transmitting the 'regAddr' field, bit 11 is sent first, and bit 8 is sent 
last.  True?

When transmitting data, bit 7 is sent first, and bit 0 is sent last.  True?

When receiving register reads during status transfers, the first two bits 
received are:  CTL[0] -> PhyControl[27] and CTL[1] -> PhyControl[26].  This 
continues down until the read data is received.  True?

Joe
From:	PJohansson@aol.com
Sent:	Friday, May 02, 1997 7:46 AM
To:	1394ohci-l@austin.ibm.com
Cc:	Carl.Humphreys@east.sun.com
Subject:	Re: Physical write error related question

In a message dated 97-05-02 02:50:54 EDT, Carl.Humphreys@East.Sun.COM (Carl
Humphreys) writes:

<< My question is this.  Is it expected that the hardware unload the 
 remaining packet in the FIFO and skip down to find the trailer quadlet 
 to obtain the 'spd' field of the originating write request - and respond 
 at that same 'spd'?  (Or is a response at the base rate spd acceptable
 given this situation to possibly prepare a concatenated response?)
  >>

Independent of the speed rules for packet concatenation (mentioned by Carl in
a later message), 1394-1995 requires that responses subactions be transmitted
at the same speed at which the corresponding request subaction was received.

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com
From:	dfensore@thoreau.nsc.com
Sent:	Friday, May 02, 1997 10:19 AM
To:	Joseph_A_Bennett@ccm.fm.intel.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: Annex B clarifications

Hi Joe,

    I have added some comments below.

Regards,

- Dave Fensore

> 
> 
>  Date: Thu, 01 May 97 09:45:00 PDT
>  From: Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com>
>  Message-Id: <Thu, 01 May 97 09:56:36 PDT_3@ccm.hf.intel.com>
>  To: 1394ohci-l@austin.ibm.com
>  Subject: Annex B clarifications
>  
>  
>  OHCI seems a little unclear in some areas of Annex B (PCI annex):
>  
>  Section B.2, Busmastering Requirements
>       If the bus master enable bit is cleared in the PCI config space, the 
>       PCI logic must 'kill' all DMA contexts.  Does this mean that hardware 
>       is clearing the run bit for all contexts?  I don't think this is 
>       necessary.  This is a very drastic thing to do, and I think software 
>       should actually kill the contexts.  There should also be a restriction 
>       on software that if the bus master bit is cleared, software must clear 
>       the run bits and wait for all active bits to go to zero before 
>       re-enabling the bus master bit.
>       
>       OHCI hardware on PCI should just stop running PCI master cycles on 
>       behalf of DMA contexts if this bit is cleared.

    I agree with this point. The text should state that the OHCI
    hardware will stop running PCI master cycles, it should not say
    that the Hardware will 'kill' the DMA contexts. However, I don't
    agree with the further restriction that software must clear the
    run bits and wait for the contexts to go inactive before
    re-enabling the bus master bit.

    I think we should keep the OHCI behavior definition clearly
    separated from the PCI configuration bit definitions to allow for
    the use of other Host buses. Assuming that the OHCI logic has no
    knowledge of the PCI bits, the clearing of the bus mastering bit
    would most likely block all pending DMAs. Therefore, depending
    upon your implementation, a DMA context may not be able to go
    inactive once the bus mastering bit gets cleared, (say for example
    it has completed a transaction and must write status to host
    memory before going inactive).

    I don't know under what circumstances software will clear the bus
    mastering bit *before* all contexts go inactive. I would guess
    this would represent a serious problem in the system. It seems
    like specifying a software reset before re-enabling this bit might
    address your concern about restarting the contexts cleanly and
    avoid the issue of building PCI config bit knowledge into the OHCI
    logic.

>  
>  Section B.3.1, Command Register
>       The paragraph refers to the MA and BM fields.  I assume 'BM' is the 
>       bus master bit, but what is 'MA'?  I assume we mean the memory space 
>       enable bit.  Better wording in this paragraph would be nice.
>       
>       In addition, all of the bits in the command register are listed as 
>       read/write.  Many of these bits are not implemented.  The PCI spec 
>       states that unimplemented bits do not need to be read/write.
>   
> 
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Friday, May 02, 1997 12:46 PM
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re[2]: Annex B clarifications


Text item: 



Comments below.
Joe


Hi Joe,

    I have added some comments below.

Regards,

- Dave Fensore

>
>
>  Date: Thu, 01 May 97 09:45:00 PDT
>  From: Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com>
>  Message-Id: <Thu, 01 May 97 09:56:36 PDT_3@ccm.hf.intel.com> 
>  To: 1394ohci-l@austin.ibm.com
>  Subject: Annex B clarifications
>
>
>  OHCI seems a little unclear in some areas of Annex B (PCI annex): 
>
>  Section B.2, Busmastering Requirements
>       If the bus master enable bit is cleared in the PCI config space, the 
>       PCI logic must 'kill' all DMA contexts.  Does this mean that hardware 
>       is clearing the run bit for all contexts?  I don't think this is
>       necessary.  This is a very drastic thing to do, and I think software
>       should actually kill the contexts.  There should also be a restriction 
>       on software that if the bus master bit is cleared, software must clear 
>       the run bits and wait for all active bits to go to zero before
>       re-enabling the bus master bit. 
>
>       OHCI hardware on PCI should just stop running PCI master cycles on 
>       behalf of DMA contexts if this bit is cleared.

    I agree with this point. The text should state that the OHCI 
    hardware will stop running PCI master cycles, it should not say 
    that the Hardware will 'kill' the DMA contexts. However, I don't 
    agree with the further restriction that software must clear the 
    run bits and wait for the contexts to go inactive before 
    re-enabling the bus master bit.

    I think we should keep the OHCI behavior definition clearly 
    separated from the PCI configuration bit definitions to allow for 
    the use of other Host buses. Assuming that the OHCI logic has no 
    knowledge of the PCI bits, the clearing of the bus mastering bit 
    would most likely block all pending DMAs. Therefore, depending upon 
    your implementation, a DMA context may not be able to go inactive 
    once the bus mastering bit gets cleared, (say for example it has 
    completed a transaction and must write status to host memory before 
    going inactive).

    I don't know under what circumstances software will clear the bus 
    mastering bit *before* all contexts go inactive. I would guess 
    this would represent a serious problem in the system. It seems 
    like specifying a software reset before re-enabling this bit might 
    address your concern about restarting the contexts cleanly and 
    avoid the issue of building PCI config bit knowledge into the OHCI 
    logic.

*******************************************************************************
The reason why I stated that OHCI software should kill the contexts is for the 
following reason:  If some piece of software randomly turns off the Master 
Enable bit, then turns it back on, there is no guarantee that the OHCI 
controller will pick up from where it left off.  Since turning off the bit is a 
very drastic thing to do, I don't think hardware should be expected to be very 
graceful about handling it.  Software should have the intelligence to shut 
hardware down.
*******************************************************************************

>
>  Section B.3.1, Command Register
>       The paragraph refers to the MA and BM fields.  I assume 'BM' is the 
>       bus master bit, but what is 'MA'?  I assume we mean the memory space 
>       enable bit.  Better wording in this paragraph would be nice.
>
>       In addition, all of the bits in the command register are listed as 
>       read/write.  Many of these bits are not implemented.  The PCI spec 
>       states that unimplemented bits do not need to be read/write.
>
>

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Type: text
X-Mailer: ELM [version 2.4 PL24]
In-Reply-To: <Thu, 01 May 97 09:56:36 PDT_3@ccm.hf.intel.com> from "Joseph A Ben
nett" at May 1, 97 09:45:00 am
Cc: 1394ohci-l@austin.ibm.com
Date: Fri, 2 May 1997 13:18:43 -0400 (EDT)
To: Joseph_A_Bennett@ccm.fm.intel.com (Joseph A Bennett)
Subject: Re: Annex B clarifications
Message-Id: <9705021719.AA22494@thoreau.nsc.com>
From: dfensore@thoreau.nsc.com (David Fensore)
Received: from lem.nsc.com by thoreau.nsc.com (4.1/SMI-4.1)
     id AA22494; Fri, 2 May 97 13:19:52 EDT
Received: from thoreau.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP
     id AA15290 for Joseph_A_Bennett@ccm.fm.intel.com; Fri, 2 May 97 10:14:19 -0
700
Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (3.2)
     id xma003025; Fri, 2 May 97 10:10:34 -0700
Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id KAA0383
7; Fri, 2 May 1997 10:11:36 -0700
Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by netma
il1.austin.ibm.com (8.6.12/8.6.11) with SMTP id MAA46748 for <1394ohci-l@austin.
ibm.com>; Fri, 2 May 1997 12:19:01 -0500
Received: from netmail1.austin.ibm.com by calliope.fm.intel.com (8.8.4/10.0i); F
ri, 2 May 1997 17:26:14 GMT
Received: from calliope.fm.intel.com (calliope.fm.intel.com [132.233.247.7]) by
fmmail.fm.intel.com (8.8.5/8.7.3) with ESMTP id KAA26826; Fri, 2 May 1997 10:26:
02 -0700 (PDT)
Return-Path: leew@austin.ibm.com
From:	dfensore@thoreau.nsc.com
Sent:	Friday, May 02, 1997 2:24 PM
To:	Joseph_A_Bennett@ccm.fm.intel.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: Re[2]: Annex B clarifications

Hi Joe,

    I think we agree here but my response may have misled you. Yes, if
some software clears the bus mastering bit, no one should assume that
you can enable this bit again without cleaning up the DMA contexts
first. I only wanted to point out that turning off run and waiting for
the DMA contexts to go inactive may not work in this case. The DMA
contexts might not ever go inactive. As you point out, this is a
drastic condition that we should not expect hardware to handle
gracefully. Therefore, if we need to specify a club for software to
use to clean this up, let's specify the big club (software reset).

Thanks and Regards,

- Dave Fensore

> 
> 
> Text item: 
> 
> 
> 
> Comments below.
> Joe
> 
> 
> Hi Joe,
> 
>     I have added some comments below.
> 
> Regards,
> 
> - Dave Fensore
> 
> >
> >
> >  Date: Thu, 01 May 97 09:45:00 PDT
> >  From: Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com>
> >  Message-Id: <Thu, 01 May 97 09:56:36 PDT_3@ccm.hf.intel.com> 
> >  To: 1394ohci-l@austin.ibm.com
> >  Subject: Annex B clarifications
> >
> >
> >  OHCI seems a little unclear in some areas of Annex B (PCI annex): 
> >
> >  Section B.2, Busmastering Requirements
> >       If the bus master enable bit is cleared in the PCI config space, the 
> >       PCI logic must 'kill' all DMA contexts.  Does this mean that hardware 
> >       is clearing the run bit for all contexts?  I don't think this is
> >       necessary.  This is a very drastic thing to do, and I think software
> >       should actually kill the contexts.  There should also be a restriction 
> >       on software that if the bus master bit is cleared, software must clear 
> >       the run bits and wait for all active bits to go to zero before
> >       re-enabling the bus master bit. 
> >
> >       OHCI hardware on PCI should just stop running PCI master cycles on 
> >       behalf of DMA contexts if this bit is cleared.
> 
>     I agree with this point. The text should state that the OHCI 
>     hardware will stop running PCI master cycles, it should not say 
>     that the Hardware will 'kill' the DMA contexts. However, I don't 
>     agree with the further restriction that software must clear the 
>     run bits and wait for the contexts to go inactive before 
>     re-enabling the bus master bit.
> 
>     I think we should keep the OHCI behavior definition clearly 
>     separated from the PCI configuration bit definitions to allow for 
>     the use of other Host buses. Assuming that the OHCI logic has no 
>     knowledge of the PCI bits, the clearing of the bus mastering bit 
>     would most likely block all pending DMAs. Therefore, depending upon 
>     your implementation, a DMA context may not be able to go inactive 
>     once the bus mastering bit gets cleared, (say for example it has 
>     completed a transaction and must write status to host memory before 
>     going inactive).
> 
>     I don't know under what circumstances software will clear the bus 
>     mastering bit *before* all contexts go inactive. I would guess 
>     this would represent a serious problem in the system. It seems 
>     like specifying a software reset before re-enabling this bit might 
>     address your concern about restarting the contexts cleanly and 
>     avoid the issue of building PCI config bit knowledge into the OHCI 
>     logic.
> 
> *******************************************************************************
> The reason why I stated that OHCI software should kill the contexts is for the 
> following reason:  If some piece of software randomly turns off the Master 
> Enable bit, then turns it back on, there is no guarantee that the OHCI 
> controller will pick up from where it left off.  Since turning off the bit is a 
> very drastic thing to do, I don't think hardware should be expected to be very 
> graceful about handling it.  Software should have the intelligence to shut 
> hardware down.
> *******************************************************************************
> 
> >
> >  Section B.3.1, Command Register
> >       The paragraph refers to the MA and BM fields.  I assume 'BM' is the 
> >       bus master bit, but what is 'MA'?  I assume we mean the memory space 
> >       enable bit.  Better wording in this paragraph would be nice.
> >
> >       In addition, all of the bits in the command register are listed as 
> >       read/write.  Many of these bits are not implemented.  The PCI spec 
> >       states that unimplemented bits do not need to be read/write.
> >
> >
From:	DavidW@bangate.compaq.com
Sent:	Friday, May 02, 1997 4:09 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Physical write error related question

Carl,

It is true that you will need to know the speed of the request in order to ack 
or respond.  Whether or not this requires that you skip to the end of the FIFO 
in order to unload a speed code is an implementation issue.

David Wooten

Carl.Humphreys@East.Sun.COM (Carl Humphreys) Wrote:
| 
| 
| 
| Thinking about the concatenation rules... unless the write request
| was at S100 anyway, concatenation of the base rate response wouldn't be
| allowed. 
| 
| In that case, it seems that you would need to find out the speed of the 
| write request that resulted in the error anyway.  If this is not true, 
| let me know.
| 
| - Carl
| 
| 
| ----- Begin Included Message -----
| 
| From carlh Thu May  1 23:52:57 1997
| To: 1394ohci-l@austin.ibm.com
| Subject: Physical write error related question
| 
| 
| 
| In a situation where a physical write request is received - which 
| has not been posted - (but has been acknowledged with an ack_pending) 
| has been successfully written into the FIFO but while transmitting to
| host memory a bus error occurs, I believe a response with rcode of 
| resp_data_error must be sent to the requesting node.
| 
| My question is this.  Is it expected that the hardware unload the 
| remaining packet in the FIFO and skip down to find the trailer quadlet 
| to obtain the 'spd' field of the originating write request - and respond 
| at that same 'spd'?  (Or is a response at the base rate spd acceptable
| given this situation to possibly prepare a concatenated response?)
| 
| - ie: as soon as the memory write error is seen, the response packet
| is scheduled without having to wait to find the trailer quadlet.
| 
| 
| Thanks,
| 
| - Carl
| 
| 
| ----- End Included Message -----
| 
| 
From:	Kugao Ouchi [Kugao_Ohuchi@el.nec.com]
Sent:	Saturday, May 03, 1997 12:27 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Subscribe


Name :     Kugao Ouchi
Company :NEC Electronics.
TEL:        408-588-5503
FAX:        408-588-5469
Address:  2880 Scott Blvd. Santa Clara CA, USA Zip: 95050
E-mail  :  Kugao_Ohuchi@el.nec.com
From:	DavidW@bangate.compaq.com
Sent:	Sunday, May 04, 1997 11:26 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: No need to back-out when ack not delivered

I sort of agree with Jerry.  However, I don't think there is any particular 
preference towards not backing things out.  I would simply suggest that one do 
what is simplest for the HW and, if its a tossup, back it out.

David Wooten


Jerry Hauck <Jerry_Hauck@ccm.sc.intel.com> Wrote:
| 
|      A change in OHCI 0.93 to section "8.4.2.2 Error Handling" includes the 
|      following paragraph pertaining to the AR DMA:
|      
|         Similarly, if a bus reset occurs after a packet has been 
|         received but before the ack is sent, the packet will be 
|         "backed-out" of the buffer(s) as described for ack_data_error 
|         above.
|      
|      I recall a reflector discussion from two months ago (between Yehuda 
|      Peled and David Wooten) which may have prompted this addition to 
|      0.93.  The thread is included at the end of this message.
|      
|      However, I do not agree that the above is required or desired 
|      behavior.  If the packet (for which the ack was aborted) was to be 
|      dispatched to the AR Request DMA, then it will be flushed by software 
|      as a result of the bus reset.  No harm in leaving the packet in the 
|      buffer with the ack code intended to be sent.  Software can still 
|      parse the buffer and ignore the packet as usual.
|      
|      If the packet was to be dispatched to the AR Response DMA, then enough 
|      of the response was received for software to retire the associated 
|      transaction before acting on the bus reset.  The responder takes the 
|      same action whether an ack is received or not.  (A responder can never 
|      retry a response for which no ack was received ... it is impossible to 
|      know whether it was the response or the ack which was lost.)  Since it 
|      makes no difference to the responder, I don't understand why we would 
|      require OHCI to throw away a perfectly valid response?
|      
|      Consequently, I request that the requirement to back-out the packet be 
|      removed (or backed-out) from the OHCI spec.  Implementations are free 
|      to either return the ack code intended to be sent by the link or back 
|      the packet out, with a preference for the former.
|      
|      Regards,
|      
|      Jerry Hauck
|      Intel Corporation
|      jerry_hauck@ccm.sc.intel.com
|      (408) 765-5528
| 
| 
| | Yehuda,
| |
| | Yes.  Back the packet out.
| |
| | David
| |
| |
| | "Yehuda Peled (972-4-8296149)" <ypeled@VNET.IBM.COM> Wrote: 
| | |
| | | David,
| | | Thanks for your response.
| | | I agree with your analysis.
| | | In our implementation, the HC will not write any status if the packet 
| | | was not sent.
| | | By the way, in the AR side, if there is a bus reset after the packet
| | | end and before we send an acknowledge, then the packet should be backed 
| | | out ?
| | |
| | | Thanks
| | |  Yehuda
| | |
| |
| 
From:	DavidW@bangate.compaq.com
Sent:	Wednesday, May 07, 1997 1:48 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: PhyControl register

I haven't seen any response to this.  Would someone who knows how this works 
please answer (Richard?)

David Wooten

Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
| 
| 
| I have made the following assumptions about the PHY Control register when 
| transmitting read register and write register requests.  Is this a correct 
| interpretation?
| 
| When transmitting the 'regAddr' field, bit 11 is sent first, and bit 8 is 
sent 
| last.  True?
| 
| When transmitting data, bit 7 is sent first, and bit 0 is sent last.  True?
| 
| When receiving register reads during status transfers, the first two bits 
| received are:  CTL[0] -> PhyControl[27] and CTL[1] -> PhyControl[26].  This 
| continues down until the read data is received.  True?
| 
| Joe
| 
From:	Mark Knecht [Mark_Knecht@phoenix.com]
Sent:	Wednesday, May 07, 1997 2:26 PM
To:	'1394 OHCI Reflector'
Subject:	RE: PhyControl register

Actually, this brings up a question that we've been having. Is anyone supplying a behavioral model of any Phy chips? Would be a help?

Anyone have any experience in this area?

Thanks,

Mark Knecht

----------
From: 	DavidW@bangate.compaq.com[SMTP:DavidW@bangate.compaq.com]
Sent: 	Wednesday, May 07, 1997 1:47 PM
To: 	1394ohci-l@austin.ibm.com
Subject: 	re: PhyControl register

I haven't seen any response to this.  Would someone who knows how this works 
please answer (Richard?)

David Wooten

Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
| 
| 
| I have made the following assumptions about the PHY Control register when 
| transmitting read register and write register requests.  Is this a correct 
| interpretation?
| 
| When transmitting the 'regAddr' field, bit 11 is sent first, and bit 8 is 
sent 
| last.  True?
| 
| When transmitting data, bit 7 is sent first, and bit 0 is sent last.  True?
| 
| When receiving register reads during status transfers, the first two bits 
| received are:  CTL[0] -> PhyControl[27] and CTL[1] -> PhyControl[26].  This 
| continues down until the read data is received.  True?
| 
| Joe
| 



From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Thursday, May 08, 1997 4:26 AM
To:	1394ohci-l
Subject:	Log of All Reflector Traffic To Date

Greetings,

    I have placed the file OHCI_ARC.zip on the 1394 OpenHCI
ftp site (ftp://www.austin.ibm.com/pub/chrptech/1394ohci/).  
This file contains all traffic on the reflector since it was started
last September.  Many thanks to John Fuller of Microsoft for 
pulling it out of their server archive file.

   Best Regards,
   Lee Wilson
From:	Richard Baker [artb@msg.tx.slr.com]
Sent:	Thursday, May 08, 1997 10:16 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[2]: PhyControl register

Joe,

You have to be careful about which end of the wire you are talking about.

FROM THE PHY POINT OF VIEW
--------------------------
The PHY/LINK interface is documented in P1394a Draft 0.07, dated April 5, 1997, in
section "5. PHY/Link interface specification".  This, like the rest of the 1394
spec, is "big endian", with bit 0 being the most significant, and always
transmitted on the interface first.

So, when the PHY register read or write LREQ command is sent to the PHY, the
requested register address most significant bit (PHY reg address bit 0) is sent in
the PHY LREQ bit stream at bit offset 4.  The remaining address bits are sent
sequentially from MS to LS bit (see P1394a "Table 5-6 ? Read request format" and
"Table 5-7 ? Write request format").

FROM THE OHCI POINT OF VIEW
---------------------------
So, yes:

OHCI PhyControl.regAddr is sent in the LREQ command MS to LS bit  (OHCI
PhyControl[11] to PhyControl[8]).


OHCI PhyControl.wrData is sent in the LREQ command MS to LS bit  (OHCI
PhyControl[7] to PhyControl[0]).


PHY STATUS
----------
But NO: Status data is NOT received via the PHY CTL[0:1].

See P1394a "5.1.2 Status", "Figure 5-3 ? Status timing", and "Table 5-10 ? Status
bits".  Status data is returned from the PHY on PHY D[0:1] under the appropriate
control code from the PHY (PHY CTL[0:1] == 2'b01).

Regards,
Richard Baker


DavidW@bangate.compaq.com wrote:
> 
> I haven't seen any response to this.  Would someone who knows how this works
> please answer (Richard?)
> 
> David Wooten
> 
> Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
> |
> |
> | I have made the following assumptions about the PHY Control register when
> | transmitting read register and write register requests.  Is this a correct
> | interpretation?
> |
> | When transmitting the 'regAddr' field, bit 11 is sent first, and bit 8 is
> sent
> | last.  True?
> |
> | When transmitting data, bit 7 is sent first, and bit 0 is sent last.  True?
> |
> | When receiving register reads during status transfers, the first two bits
> | received are:  CTL[0] -> PhyControl[27] and CTL[1] -> PhyControl[26].  This
> | continues down until the read data is received.  True?
> |
> | Joe
> |
From:	John Nels Fuller
Sent:	Thursday, May 08, 1997 10:45 AM
To:	'Lee Wilson'; 1394ohci-l
Subject:	RE: Log of All Reflector Traffic To Date

The OHCI_ARC.zip file actually contains two copies of the archive:
	1.	A plain text file, messages in chronological
		order.
	2.	An Exchange mail folder, the Exchange
		client that comes with Windows 95 or
		Windows NT 4.0 may be used to sort and/or
		search the archive.

> -----Original Message-----
> From:	Lee Wilson [SMTP:leew@austin.ibm.com]
> Sent:	Thursday, May 08, 1997 4:26 AM
> To:	1394ohci-l
> Subject:	Log of All Reflector Traffic To Date
> 
> Greetings,
> 
>     I have placed the file OHCI_ARC.zip on the 1394 OpenHCI
> ftp site (ftp://www.austin.ibm.com/pub/chrptech/1394ohci/).  
> This file contains all traffic on the reflector since it was started
> last September.  Many thanks to John Fuller of Microsoft for 
> pulling it out of their server archive file.
> 
>    Best Regards,
>    Lee Wilson
From:	Mark Knecht [Mark_Knecht@phoenix.com]
Sent:	Thursday, May 08, 1997 11:42 AM
To:	'1394 OHCI Reflector'
Subject:	RE: Re[2]: PhyControl register

Richard/Joe,

   OK. I'll ask "Where do I get a copy of the 0.07 draft of the 1394a specification?"

   Is there an ftp site?

Thanks,

Mark Knecht

----------
From: 	Richard Baker[SMTP:artb@msg.tx.slr.com]
Sent: 	Thursday, May 08, 1997 10:16 AM
To: 	1394ohci-l@austin.ibm.com
Subject: 	Re[2]: PhyControl register

Joe,

You have to be careful about which end of the wire you are talking about.

FROM THE PHY POINT OF VIEW
--------------------------
The PHY/LINK interface is documented in P1394a Draft 0.07, dated April 5,
 1997, in
section "5. PHY/Link interface specification".  This, like the rest of th
e 1394
spec, is "big endian", with bit 0 being the most significant, and always
transmitted on the interface first.

So, when the PHY register read or write LREQ command is sent to the PHY, 
the
requested register address most significant bit (PHY reg address bit 0) i
s sent in
the PHY LREQ bit stream at bit offset 4.  The remaining address bits are 
sent
sequentially from MS to LS bit (see P1394a "Table 5-6 =97 Read request fo
rmat" and
"Table 5-7 =97 Write request format").

FROM THE OHCI POINT OF VIEW
---------------------------
So, yes:

OHCI PhyControl.regAddr is sent in the LREQ command MS to LS bit  (OHCI
PhyControl[11] to PhyControl[8]).


OHCI PhyControl.wrData is sent in the LREQ command MS to LS bit  (OHCI
PhyControl[7] to PhyControl[0]).


PHY STATUS
----------
But NO: Status data is NOT received via the PHY CTL[0:1].

See P1394a "5.1.2 Status", "Figure 5-3 =97 Status timing", and "Table 5-1
0 =97 Status
bits".  Status data is returned from the PHY on PHY D[0:1] under the appr
opriate
control code from the PHY (PHY CTL[0:1] =3D=3D 2'b01).

Regards,
Richard Baker


DavidW@bangate.compaq.com wrote:
> 
> I haven't seen any response to this.  Would someone who knows how this 
works
> please answer (Richard?)
> 
> David Wooten
> 
> Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
> |
> |
> | I have made the following assumptions about the PHY Control register 
when
> | transmitting read register and write register requests.  Is this a co
rrect
> | interpretation?
> |
> | When transmitting the 'regAddr' field, bit 11 is sent first, and bit 
8 is
> sent
> | last.  True?
> |
> | When transmitting data, bit 7 is sent first, and bit 0 is sent last. 
 True?
> |
> | When receiving register reads during status transfers, the first two 
bits
> | received are:  CTL[0] -> PhyControl[27] and CTL[1] -> PhyControl[26].
  This
> | continues down until the read data is received.  True?
> |
> | Joe
> |



From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Thursday, May 08, 1997 11:36 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[3]: PhyControl register


Text item: 


        > Comments embedded below. Joe

______________________________ Reply Separator _________________________________
Subject: Re[2]: PhyControl register
Author:  leew@austin.ibm.com at SMTPGATE
Date:    5/8/97 12:16 PM


Joe,

You have to be careful about which end of the wire you are talking about.

FROM THE PHY POINT OF VIEW
--------------------------
The PHY/LINK interface is documented in P1394a Draft 0.07, dated April 5, 1997, 
in section "5. PHY/Link interface specification".  This, like the rest of the 
1394 spec, is "big endian", with bit 0 being the most significant, and always 
transmitted on the interface first.

So, when the PHY register read or write LREQ command is sent to the PHY, the 
requested register address most significant bit (PHY reg address bit 0) is sent 
in the PHY LREQ bit stream at bit offset 4.  The remaining address bits are sent
sequentially from MS to LS bit (see P1394a "Table 5-6 =97 Read request format" 
and "Table 5-7 =97 Write request format").

FROM THE OHCI POINT OF VIEW
---------------------------
So, yes:

OHCI PhyControl.regAddr is sent in the LREQ command MS to LS bit  (OHCI 
PhyControl[11] to PhyControl[8]).


OHCI PhyControl.wrData is sent in the LREQ command MS to LS bit  (OHCI 
PhyControl[7] to PhyControl[0]).


PHY STATUS
----------
But NO: Status data is NOT received via the PHY CTL[0:1].

See P1394a "5.1.2 Status", "Figure 5-3 =97 Status timing", and "Table 5-1= 
0 =97 Status
bits".  Status data is returned from the PHY on PHY D[0:1] under the appr= 
opriate
control code from the PHY (PHY CTL[0:1] =3D=3D 2'b01).

     > I screwed up.  I meant D[0:1], not CTL[0:1].  But my question still
     > stands: on data being returned from the PHY on a STATUS transfer for 
     > register read, what is the order?  Here is my assumption:
     >
     > Status Clock   D[0]                    D[1]            Notes
     > ------------------------------------------------------------------------
     > 1st            -                                       (1st status clock)
     > 2nd            -                                       (2nd status clock)
     > 3rd            PhyControl[27]          PhyControl[26]  (rdAddr)
     > 4th            PhyControl[25]          PhyControl[24]     "
     > 5th            PhyControl[23]          PhyControl[22]  (rdData)
     > 6th            Phycontrol[21]          PhyControl[20]     "
     > 7th            PhyControl[19]          PhyControl[18]     "
     > 8th            PhyControl[17]          PhyControl[16]     "
        

Regards,
Richard Baker


DavidW@bangate.compaq.com wrote:
>=20
> I haven't seen any response to this.  Would someone who knows how this = 
works
> please answer (Richard?)
>=20
> David Wooten
>=20
> Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote: 
> |
> |
> | I have made the following assumptions about the PHY Control register = 
when
> | transmitting read register and write register requests.  Is this a co= 
rrect
> | interpretation?
> |
> | When transmitting the 'regAddr' field, bit 11 is sent first, and bit = 
8 is
> sent
> | last.  True?
> |
> | When transmitting data, bit 7 is sent first, and bit 0 is sent last. =
 True?
> |
> | When receiving register reads during status transfers, the first two = 
bits
> | received are:  CTL[0] -> PhyControl[27] and CTL[1] -> PhyControl[26].=
  This
> | continues down until the read data is received.  True? 
> |
> | Joe
> |

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

X-MIME-Autoconverted: from 8bit to quoted-printable by jester.ti.com id MAA16572

Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=iso-8859-1
Subject: Re[2]: PhyControl register
To: 1394ohci-l@austin.ibm.com
MIME-Version: 1.0
X-Mailer: Mozilla 2.01 (X11; I; SunOS 4.1.3 sun4m)
From: Richard Baker <artb@msg.tx.slr.com>
Date: Thu, 08 May 1997 12:16:09 -0500
Message-ID: <33720A59.31D2DE92@msg.tx.slr.com>
Sender: rtb@robin.itg.ti.com
Received: from artb ([158.116.187.33]) by robin.itg.ti.com (8.7.3/8.6.11) with S
MTP id MAA29501 for <1394ohci-l@austin.ibm.com>; Thu, 8 May 1997 12:20:26 -0500
(CDT)
Received: from robin.itg.ti.com ([172.25.2.75]) by jester.ti.com (8.8.5) with ES
MTP id MAA16572 for <1394ohci-l@austin.ibm.com>; Thu, 8 May 1997 12:20:32 -0500
(CDT)
Received: from jester.ti.com (jester.ti.com [192.94.94.1]) by netmail.austin.ibm
.com (8.6.12/8.6.11) with ESMTP id MAA41388 for <1394ohci-l@austin.ibm.com>; Thu
, 8 May 1997 12:18:53 -0500
Received: from netmail.austin.ibm.com by thalia.fm.intel.com (8.8.4/10.0i); Thu,
 8 May 1997 17:29:10 GMT
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by fmm
ail.fm.intel.com (8.8.5/8.7.3) with ESMTP id KAA13418; Thu, 8 May 1997 10:29:51
-0700 (PDT)
Return-Path: leew@austin.ibm.com
From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Thursday, May 08, 1997 7:14 AM
To:	1394ohci-l
Subject:	RE: Log of All Reflector Traffic To Date

Greetings,

    The text file is zipped - OHCI_ARC.zip.   The Microsoft
exchange file is OHCI_ARC.pst.   To use this under Exchange,
go to "Tools", then "Services", then "Add a Personal Folder".
You will enter the file name "ohci_arc.pst".

     John originally sent me the two files zipped together, 
uuencoded, etc.  I split them apart and tested them before 
putting them on the ftp site.  They are now separate files.

    Best Regards,
    Lee

To: leew @ austin.ibm.com ("'Lee Wilson'") @ AUSSMTP, 1394ohci-l @ 
austin.ibm.com @ AUSSMTP
cc:  (bcc: Lee Wilson)
From: jfuller @ MICROSOFT.com (John Nels Fuller) @ AUSSMTP
Date: 05/08/97 10:44:55 AM
Subject: RE: Log of All Reflector Traffic To Date
Security: 
 
The OHCI_ARC.zip file actually contains two copies of the archive:
 1. A plain text file, messages in chronological
  order.
 2. An Exchange mail folder, the Exchange
  client that comes with Windows 95 or
  Windows NT 4.0 may be used to sort and/or
  search the archive.

> -----Original Message-----
> From: Lee Wilson [SMTP:leew@austin.ibm.com]
> Sent: Thursday, May 08, 1997 4:26 AM
> To: 1394ohci-l
> Subject: Log of All Reflector Traffic To Date
> 
> Greetings,
> 
>     I have placed the file OHCI_ARC.zip on the 1394 OpenHCI
> ftp site (ftp://www.austin.ibm.com/pub/chrptech/1394ohci/).  
> This file contains all traffic on the reflector since it was started
> last September.  Many thanks to John Fuller of Microsoft for 
> pulling it out of their server archive file.
> 
>    Best Regards,
>    Lee Wilson

  
From:	Richard Baker [artb@msg.tx.slr.com]
Sent:	Thursday, May 08, 1997 12:05 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re[4]: PhyControl register

Joe,

I think you are correct.

Regards,
Richard Baker

Phone: 512/425-6205    FAX: 512/425-7023   email: rtb@artb.itg.ti.com
 
-- Solectron Texas --- System Design Engineering --- Austin, Texas --
 

Joseph A Bennett wrote:
>
. . . .
>>But my question still
>> stands: on data being returned from the PHY on a STATUS transfer for
>> register read, what is the order?  Here is my assumption:
>>
>> Status Clock   D[0]                    D[1]            Notes
>> ------------------------------------------------------------------------
>> 1st            -                                       (1st status clock)
>> 2nd            -                                       (2nd status clock)
>> 3rd            PhyControl[27]          PhyControl[26]  (rdAddr)
>> 4th            PhyControl[25]          PhyControl[24]     "
>> 5th            PhyControl[23]          PhyControl[22]  (rdData)
>> 6th            Phycontrol[21]          PhyControl[20]     "
>> 7th            PhyControl[19]          PhyControl[18]     "
>> 8th            PhyControl[17]          PhyControl[16]     "
>
. . . .
>
From:	YOUNG, MARK [MARKYOUNG@TX.SLR.COM]
Sent:	Thursday, May 08, 1997 2:42 PM
To:	'1394ohci-l@austin.ibm.com'
Subject:	RE: 0.91 notes

Table 8-5's xferStatus incorrectly refers to the the descriptor
xferStatus and should describe the RCV'ed data field. This was reported
in OHCI 0.91 (per 1b below) and is still wrong in 0.93? 

I believe xferStatus event codes here should be : ack_complete,
ack_pending, ack_type_error (per David Wotan in message 4/4/97)
evt_no_status for PHY_CFG, and evt_bus_reset.

>----------
>From: 	mis@aluxs.micro.lucent.com[SMTP:mis@aluxs.micro.lucent.com]
>Sent: 	Wednesday, February 05, 1997 12:46PM
>To: 	1394ohci-l@austin.ibm.com
>Subject: 	0.91 notes
>
>Hi all,
>Here is a short list of notes against 0.91 OHCI:
>
>1.	Table 8-5 timeStamp field description is different from Table 8-3. 
>1a.	xferStatus field in table 8-5 appears to describe xferStatus field in the
>descriptor (this table describes fields in the data buffer).
>1b.	Table 8-3 is a subset of table 8-5. For clarity maybe one table should
>refer to the other.
>
>2.	Fig 9-10 title: What is "cycleNumber" referring to?
>
>3.	Sec 10.2.2.1: This section implies that s=1, whereas in 10.1 for
>pkt/buffer mode s= 0 or 1. 
>
>Thank you for your time,
>
>Michael Shinkarovsky		mshinkarovsky@lucent.com
>Lucent Technologies		Tel: +1 610 712 2938
>Microelectronics Group		Fax: +1 610 712 2820
>
From:	Ron Mosgrove [Ron_Mosgrove@ccm.jf.intel.com]
Sent:	Thursday, May 08, 1997 4:09 PM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

     subscribe
     
     If there's actually a human behind this, please add me to the 
     reflector.
     Thanks,
     
     Ron Mosgrove
     Ron_Mosgrove@ccm.jf.intel.com
     Intel Corp
     2111 NE 25th Ave
     Hillsboro, OR  97229
From:	PJohansson@aol.com
Sent:	Friday, May 09, 1997 7:05 AM
To:	1394ohci-l@austin.ibm.com
Cc:	Mark_Knecht@phoenix.com
Subject:	Re: Re[2]: PhyControl register

In a message dated 97-05-08 15:07:29 EDT, Mark_Knecht@phoenix.com (Mark
Knecht) writes:

<< Where do I get a copy of the 0.07 draft of the 1394a specification? >>

ftp://ftp.symbios.com/pub/standards/io/1394/P1394a

Check out DocumentIndex.txt while you're there.

The drafts are in /Drafts.

Regards,

Peter Johansson
Chair, IEEE P1394a

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com
From:	Debkumar [debkumar@ami.com]
Sent:	Friday, May 09, 1997 7:24 AM
To:	'1394ohci-l@austin.ibm.com'
Subject:	subscribe


subscribe

Thanks and regards

Name		: Debkumar  De
Company	: American Megatrends, Inc.
Email		: debkumar@ami.com
Phone		: 770-246-8666
Fax		: 770-246-8791
From:	Aashutosh Joshi [aashutosh@ami.com]
Sent:	Friday, May 09, 1997 8:23 AM
To:	'1394 Mail List'
Subject:	Subscribe

	
Aashutosh Joshi

BIOS Engineer
American Megatrends, Inc.
6145F Norhtbelt Parkway
Norcross GA 30071

Direct	:	770 246 8759
Main	:	770 246 8600
Fax	:	770 246 8791
Email	:	aashutosh@ami.com
From:	amrits@eng.adaptec.com
Sent:	Friday, May 09, 1997 4:58 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Transmit Headers

Hi,

I may be missing out on some basic information that led to
the requirement of using OUT_MORE_IMMEDIATE instructions for
transmit headers. This forces s/w to place the header in 
descriptor block while transmit data is in a separate memory
buffer.
 
It may be easier for s/w (in some cases) to DMA the header 
and data from a single memory buffer into OHCI chip.
Asynch as well as Isoch transmit may have such cases.

If OUT_MORE_IMMIDIATE instruction can be allowed to
have a reqCount of zero, that will allow packet headers
to be acquired from the same location as data.

Can someone clarify this please?

Thanks,
-amrit
From:	amrits@eng.adaptec.com
Sent:	Friday, May 09, 1997 5:58 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Asynchronous Transmit Retries

Hi,

Relationships among retries and fresh transmit packets of
different kind are explained quite well on page-31 (0.93).
These relationships seem to require an implementation
that has three separate FIFOs. (One each for AT request,
AT response, and Physical response). Short of these
separate FIFOs, h/w will have a very tough time trying
to pause retrying packets, transmitting a fresh packet,
and then to resume retrying. Add to this the complication
caused by large packets that don't fit into the FIFO, since
these packets have to be refetched for every retry.

It seems excessive to require hardware to have three FIFOs
for asynchronous transmit.

Why can`t transaction layer manage these retry relationships
after programming low retry counts into AT Retries register?

Any and all help would be appreciated.

Thanks,
-amrit
From:	D. Suresh [D.Suresh@utopia.hclt.com]
Sent:	Monday, May 12, 1997 12:39 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Transmit timings, PHY to LINK interface

Hi

In p1394a, under 5.1.3 Transmit (page 42)  the following statement is
confusing me.  "If the PHY wins the arbitration, it grants the bus to
the Link by asserting transmit on the Ctl signals for one Sclk cycle,
followed by idle for one cycle. After sampling the transmit state from
the PHY, the Link asserts idle for one clock and takes the control of
the interface by asserting either hold or transmit on the Ctl bus"

My question  : Can Link and PHY simultaneously drive the Ctl lines
with Idle for one Sclk period ? 

 The Figure 5.4 Transmit Timing  (page 43) shows only one Idle  cycle
between the Link and PHY ownership change.

Thank you  for the  time

Regards
Suresh
D. Suresh
HCL Technologies,
(A Division of HCL Conculting Limited)
#50-53, Greams Road,
Madras 600 006
India.

Ph   : +91 -44 8279312, 8275866.
Fax  : +91 -44 8278969
email: dsuresh@hclt.com
From:	DavidW@bangate.compaq.com
Sent:	Monday, May 12, 1997 6:19 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Transmit Headers

Amrit,

The were two main reasons why OUT_MORE_IMMEDIATE is used for headers.  First, 
having several different ways of specifying the header did not seem to be 
particularly valuable to SW and having multiple ways of specifying the header 
was an added complexity to the HW.  Second, it reduced the number of memory 
fetches that were required to send a packet.  There is some concern that the 
overhead cycles will be a serious performance limiter for a host controller.  
Having the packet header be embedded in the descriptor will reduce the 
overhead cycles and allow more consistent behavior.

David

amrits@eng.adaptec.com (Amrit Sra x2202) Wrote:
| 
| Hi,
| 
| I may be missing out on some basic information that led to
| the requirement of using OUT_MORE_IMMEDIATE instructions for
| transmit headers. This forces s/w to place the header in 
| descriptor block while transmit data is in a separate memory
| buffer.
|  
| It may be easier for s/w (in some cases) to DMA the header 
| and data from a single memory buffer into OHCI chip.
| Asynch as well as Isoch transmit may have such cases.
| 
| If OUT_MORE_IMMIDIATE instruction can be allowed to
| have a reqCount of zero, that will allow packet headers
| to be acquired from the same location as data.
| 
| Can someone clarify this please?
| 
| Thanks,
| -amrit
| 
From:	DavidW@bangate.compaq.com
Sent:	Monday, May 12, 1997 6:31 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Asynchronous Transmit Retries

I don't know why you think you need separate response FIFO's.  I could imagine 
that you would want to have separate 'descriptors' for AT request, AT 
response, and physical response (a pseudo descriptor will need to exist for 
physical response.)  All you need to do is to arbitrate for the order in which 
you will try to send the packets.  Whichever one wins is the one you put into 
the output FIFO.  Then, you send that packet and put one of the remaining 
types into the FIFO and return the ack response to the context.  If the 
context gets a busy ack, you put the same command back in the arbitration 
queue (if it hasn't used up its retry count.)  

Note, you may not allow the busy state of any of AT request, AT response or 
physical response block the transmission of either of the other two.  Also, if 
something gets stuck in the FIFO and a bus reset occurs before it is sent, you 
must flush the FIFO.

David Wooten

amrits@eng.adaptec.com (Amrit Sra x2202) Wrote:
| 
| Hi,
| 
| Relationships among retries and fresh transmit packets of
| different kind are explained quite well on page-31 (0.93).
| These relationships seem to require an implementation
| that has three separate FIFOs. (One each for AT request,
| AT response, and Physical response). Short of these
| separate FIFOs, h/w will have a very tough time trying
| to pause retrying packets, transmitting a fresh packet,
| and then to resume retrying. Add to this the complication
| caused by large packets that don't fit into the FIFO, since
| these packets have to be refetched for every retry.
| 
| It seems excessive to require hardware to have three FIFOs
| for asynchronous transmit.
| 
| Why can`t transaction layer manage these retry relationships
| after programming low retry counts into AT Retries register?
| 
| Any and all help would be appreciated.
| 
| Thanks,
| -amrit
| 
From:	DavidW@bangate.compaq.com
Sent:	Monday, May 12, 1997 6:37 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: Transmit timings, PHY to LINK interface

This question should be addressed to the p1394a reflector 
(1394-sig@1394ta.org).

David Wooten


"D. Suresh" <D.Suresh@utopia.hclt.com> Wrote:
| 
| Hi
| 
| In p1394a, under 5.1.3 Transmit (page 42)  the following statement is
| confusing me.  "If the PHY wins the arbitration, it grants the bus to
| the Link by asserting transmit on the Ctl signals for one Sclk cycle,
| followed by idle for one cycle. After sampling the transmit state from
| the PHY, the Link asserts idle for one clock and takes the control of
| the interface by asserting either hold or transmit on the Ctl bus"
| 
| My question  : Can Link and PHY simultaneously drive the Ctl lines
| with Idle for one Sclk period ? 
| 
|  The Figure 5.4 Transmit Timing  (page 43) shows only one Idle  cycle
| between the Link and PHY ownership change.
| 
| Thank you  for the  time
| 
| Regards
| Suresh
| D. Suresh
| HCL Technologies,
| (A Division of HCL Conculting Limited)
| #50-53, Greams Road,
| Madras 600 006
| India.
| 
| Ph   : +91 -44 8279312, 8275866.
| Fax  : +91 -44 8278969
| email: dsuresh@hclt.com
| 
From:	John Nels Fuller
Sent:	Monday, May 12, 1997 10:20 AM
To:	'DavidW@bangate.compaq.com'; 1394ohci-l@austin.ibm.com
Subject:	RE: Transmit Headers

There are some additional reasons:

There are fields in the headers that must be filled in by the 1394 bus
driver, not by the application/driver generating the data portion of the
packet.  These include the phy-id of the destination (we expect the
application to simply specify the EUI-64 of the destination and that the
bus driver will associate it with the current phy-id) and the
transaction label (which is used by the bus driver to associate the
response with the original request).  Since these fields must be
manipulated by the bus driver it is most convenient to have them in the
descriptor and not in the data, any performance savings the application
may see by placing the header with the data will be undone by the added
complexity of the bus driver.

> -----Original Message-----
> From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
> Sent:	Monday, May 12, 1997 6:19 AM
> To:	1394ohci-l@austin.ibm.com
> Subject:	re: Transmit Headers
> 
> Amrit,
> 
> The were two main reasons why OUT_MORE_IMMEDIATE is used for headers.
> First, 
> having several different ways of specifying the header did not seem to
> be 
> particularly valuable to SW and having multiple ways of specifying the
> header 
> was an added complexity to the HW.  Second, it reduced the number of
> memory 
> fetches that were required to send a packet.  There is some concern
> that the 
> overhead cycles will be a serious performance limiter for a host
> controller.  
> Having the packet header be embedded in the descriptor will reduce the
> 
> overhead cycles and allow more consistent behavior.
> 
> David
> 
> amrits@eng.adaptec.com (Amrit Sra x2202) Wrote:
> | 
> | Hi,
> | 
> | I may be missing out on some basic information that led to
> | the requirement of using OUT_MORE_IMMEDIATE instructions for
> | transmit headers. This forces s/w to place the header in 
> | descriptor block while transmit data is in a separate memory
> | buffer.
> |  
> | It may be easier for s/w (in some cases) to DMA the header 
> | and data from a single memory buffer into OHCI chip.
> | Asynch as well as Isoch transmit may have such cases.
> | 
> | If OUT_MORE_IMMIDIATE instruction can be allowed to
> | have a reqCount of zero, that will allow packet headers
> | to be acquired from the same location as data.
> | 
> | Can someone clarify this please?
> | 
> | Thanks,
> | -amrit
> | 
From:	John Nels Fuller
Sent:	Monday, May 12, 1997 10:27 AM
To:	'DavidW@bangate.compaq.com'; 1394ohci-l@austin.ibm.com
Subject:	RE: Transmit timings, PHY to LINK interface

Sorry, David, the official IEEE P1394a reflector is p1394@sun.com,
although you may want to copy the message to
1394-architecture@1394ta.org which is the TA's architecture working
group reflector.

The 1394-sig@1394ta.org reflector is much broader and is typically used
for non-technical issues.

> -----Original Message-----
> From:	DavidW@bangate.compaq.com [SMTP:DavidW@bangate.compaq.com]
> Sent:	Monday, May 12, 1997 6:37 AM
> To:	1394ohci-l@austin.ibm.com
> Subject:	re: Transmit timings, PHY to LINK interface
> 
> This question should be addressed to the p1394a reflector 
> (1394-sig@1394ta.org).
> 
> David Wooten
> 
> 
> "D. Suresh" <D.Suresh@utopia.hclt.com> Wrote:
> | 
> | Hi
> | 
> | In p1394a, under 5.1.3 Transmit (page 42)  the following statement
> is
> | confusing me.  "If the PHY wins the arbitration, it grants the bus
> to
> | the Link by asserting transmit on the Ctl signals for one Sclk
> cycle,
> | followed by idle for one cycle. After sampling the transmit state
> from
> | the PHY, the Link asserts idle for one clock and takes the control
> of
> | the interface by asserting either hold or transmit on the Ctl bus"
> | 
> | My question  : Can Link and PHY simultaneously drive the Ctl lines
> | with Idle for one Sclk period ? 
> | 
> |  The Figure 5.4 Transmit Timing  (page 43) shows only one Idle
> cycle
> | between the Link and PHY ownership change.
> | 
> | Thank you  for the  time
> | 
> | Regards
> | Suresh
> | D. Suresh
> | HCL Technologies,
> | (A Division of HCL Conculting Limited)
> | #50-53, Greams Road,
> | Madras 600 006
> | India.
> | 
> | Ph   : +91 -44 8279312, 8275866.
> | Fax  : +91 -44 8278969
> | email: dsuresh@hclt.com
> | 
From:	Madhsudan Hans [hansm@madmats.esd.sgi.com]
Sent:	Monday, May 12, 1997 12:15 PM
To:	1394ohci-l@austin.ibm.com
Cc:	hansm@madmats.esd.sgi.com
Subject:	DMA Addresses

Hi,

With processors now able to access up to 64GB of physical memory (36-bit
addressing) wouldn't it be advantageous to define "extra" bits in the
descriptor dataAddress field and the commandPtr registers instead of
restricting DMA access to 4GB (32-bit addressing).

Thanks.


-- 
Madhsudan Hans
Silicon Graphics, Inc
Mountain View CA
hansm@sgi.com
From:	John Nels Fuller
Sent:	Monday, May 12, 1997 1:15 PM
To:	'Madhsudan Hans'; 1394ohci-l@austin.ibm.com
Subject:	RE: DMA Addresses

OpenHCI version 1.00 is intended to be a 32-bit adapter so we don't want
to do these things.  We have given thought to a full 64-bit version of
OpenHCI but that work is not ready for prime time.

However, since software has learned to deal with this kind of
restriction before (when systems went from 16 to 32 bits) most OS's
already have the tools present to handle this restriction.  And since
the majority of transfers are expected to be handled by the physical
request/response units, an interim solution to the addressing problem
may be a fairly simple enhancement to the physical request/response
units to allow them to use more address bits.

Nonetheless, my personal opinion is that we should get version 1.00 out
first and start seeing 32-bit PCI cards become available to prove the
design before we go out and muddy the waters with greater than 32 bit
addressing.

> -----Original Message-----
> From:	Madhsudan Hans [SMTP:hansm@madmats.esd.sgi.com]
> Sent:	Monday, May 12, 1997 12:15 PM
> To:	1394ohci-l@austin.ibm.com
> Cc:	hansm@madmats.esd.sgi.com
> Subject:	DMA Addresses
> 
> Hi,
> 
> With processors now able to access up to 64GB of physical memory
> (36-bit
> addressing) wouldn't it be advantageous to define "extra" bits in the
> descriptor dataAddress field and the commandPtr registers instead of
> restricting DMA access to 4GB (32-bit addressing).
> 
> Thanks.
> 
> 
> -- 
> Madhsudan Hans
> Silicon Graphics, Inc
> Mountain View CA
> hansm@sgi.com
From:	Madhsudan Hans [hansm@madmats.esd.sgi.com]
Sent:	Monday, May 12, 1997 12:15 PM
To:	1394ohci-l@austin.ibm.com
Cc:	hansm@madmats.esd.sgi.com
Subject:	DMA Addresses

Hi,

With processors now able to access up to 64GB of physical memory (36-bit
addressing) wouldn't it be advantageous to define "extra" bits in the
descriptor dataAddress field and the commandPtr registers instead of
restricting DMA access to 4GB (32-bit addressing).

Thanks.


-- 
Madhsudan Hans
Silicon Graphics, Inc
Mountain View CA
hansm@sgi.com
From:	Oscar R. Mitchell [Oscar.Mitchell@Skipstone.com]
Sent:	Monday, May 12, 1997 2:01 PM
To:	John Nels Fuller
Cc:	'Madhsudan Hans'; 1394ohci-l@austin.ibm.com
Subject:	RE: DMA Addresses

Importance:	High

My two cents.

First, let me condition my statements by saying "I have not looked at the OpenHCI spec
in a while", however, IF the current definition of the PRU does not map addresses with
non-zero upper address bits into an "invalid address" indication to the sender, then
we will have incompatibility problems when the hardware really does support the full
48 bit address space of each node.

Also, I believe that even though the current implementation of OHCI is 32 bits, all 
registers/fields relating to addresses should be defined mindful of the eventual need 
to transition 48/64 bit addressing.

Let us not recreate/relive the problems that the mainframe and 68k world had when they
transitioned from their "20-something" bit addresses to 32 bit addresses, and programmers
had use the upper "unused" address bits for non-standard and incompatible things. 
Especially in light of the fact that IEEE1394-1995 is already defined as a 64 Bit memory 
space and OHCI is being defined "after the fact".

Please don't hesitate to let me know if I'm off-base...

Regards,
Oscar.


At 01:14 PM 5/12/97 -0700, John Nels Fuller wrote:
>OpenHCI version 1.00 is intended to be a 32-bit adapter so we don't want
>to do these things.  We have given thought to a full 64-bit version of
>OpenHCI but that work is not ready for prime time.
>
>However, since software has learned to deal with this kind of
>restriction before (when systems went from 16 to 32 bits) most OS's
>already have the tools present to handle this restriction.  And since
>the majority of transfers are expected to be handled by the physical
>request/response units, an interim solution to the addressing problem
>may be a fairly simple enhancement to the physical request/response
>units to allow them to use more address bits.
>
>Nonetheless, my personal opinion is that we should get version 1.00 out
>first and start seeing 32-bit PCI cards become available to prove the
>design before we go out and muddy the waters with greater than 32 bit
>addressing.
>
>> -----Original Message-----
>> From:	Madhsudan Hans [SMTP:hansm@madmats.esd.sgi.com]
>> Sent:	Monday, May 12, 1997 12:15 PM
>> To:	1394ohci-l@austin.ibm.com
>> Cc:	hansm@madmats.esd.sgi.com
>> Subject:	DMA Addresses
>> 
>> Hi,
>> 
>> With processors now able to access up to 64GB of physical memory
>> (36-bit
>> addressing) wouldn't it be advantageous to define "extra" bits in the
>> descriptor dataAddress field and the commandPtr registers instead of
>> restricting DMA access to 4GB (32-bit addressing).
>> 
>> Thanks.
>> 
>> 
>> -- 
>> Madhsudan Hans
>> Silicon Graphics, Inc
>> Mountain View CA
>> hansm@sgi.com
>


<<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>>
Oscar R. Mitchell
  Engineering Manager, Peripheral Technology Solutions Group
 Adaptec, Corporation  -:-  "The IEEE-1394 Serial Bus Experts" (tm)
 Austin Technology Center
 3925 West Braker Lane -  Suite 425
 Austin,  Texas  78759

  (512) 305-0200 Voice
  (512) 251-5470 Fax  (or 512 305-0212)

      oscar.mitchell@skipstone.com  -or- oscar@skipstone.com

URL: http://www.adaptec.com/  -or-  http://www.skipstone.com/

#include <witty.saying>
#include <clever.graphic>
#include <std.disclaimer>
From:	DavidW@bangate.compaq.com
Sent:	Monday, May 12, 1997 2:06 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: DMA Addresses

I think that the intent is for someone to sit down and work out all the 
details of a proper 64-bit interface including having larger addresses in the 
descriptors and larger address registers.  If you would like to sit down with 
Sun and others and put together a proposal, we would be glad to help in the 
review process.

Meanwhile, we think that 32-bits is enough for a lot of applications and we 
did not want everyone to have to pay the cost of larger address space.  That's 
why >4GB support is not part of the first OHCI standard.

David

"Madhsudan Hans" <hansm@madmats.esd.sgi.com> Wrote:
| 
| Hi,
| 
| With processors now able to access up to 64GB of physical memory (36-bit
| addressing) wouldn't it be advantageous to define "extra" bits in the
| descriptor dataAddress field and the commandPtr registers instead of
| restricting DMA access to 4GB (32-bit addressing).
| 
| Thanks.
| 
| 
| -- 
| Madhsudan Hans
| Silicon Graphics, Inc
| Mountain View CA
| hansm@sgi.com
| 
From:	John Nels Fuller
Sent:	Monday, May 12, 1997 3:32 PM
To:	'Oscar R. Mitchell'
Cc:	'Madhsudan Hans'; 1394ohci-l@austin.ibm.com
Subject:	RE: DMA Addresses

The current definition of the PRU says that if the address is >4GB then
the packet will be delivered to the AR request context for the software
to deal with.  Additionally, get it out of your mind that this is a
memory bus!  It is not!  No device should be using addresses that aren't
implicitly known by virtue of the protocol being used or explicitly
passed by such a protocol.  Devices do not randomly touch addresses to
see what is there, if they do they get what they deserve!

As for 64 bitness, we have attempted to ensure that every 32-bit
register in OpenHCI that contains a host address has a 32-bit reserved
register adjacent to it that will allow us to expand that address in the
future.  There are still problems to be solved with taking DMA
descriptors to 64 bit addressing (we don't like the DBDMA solution, nor
do we want to expand descriptor commands to 5 quadlets).

But as I said before, the vast majority of what goes on is in the
physical units which does not need much of a host side interface to be
expanded to nearly 48 bit addressing.  Since most of what traffic is
left to be handled by software is of the nature of overhead structures
typically allocated by device drivers, I believe that the restriction
that these things be below 4GB is not a problem.  Therefore, I believe
that just doing something so that the physical units can address more
memory will perform at least 95% as well as a full 64-bit controller
solution.

> -----Original Message-----
> From:	Oscar R. Mitchell [SMTP:Oscar.Mitchell@Skipstone.com]
> Sent:	Monday, May 12, 1997 2:01 PM
> To:	John Nels Fuller
> Cc:	'Madhsudan Hans'; 1394ohci-l@austin.ibm.com
> Subject:	RE: DMA Addresses
> Importance:	High
> 
> My two cents.
> 
> First, let me condition my statements by saying "I have not looked at
> the OpenHCI spec
> in a while", however, IF the current definition of the PRU does not
> map addresses with
> non-zero upper address bits into an "invalid address" indication to
> the sender, then
> we will have incompatibility problems when the hardware really does
> support the full
> 48 bit address space of each node.
> 
> Also, I believe that even though the current implementation of OHCI is
> 32 bits, all 
> registers/fields relating to addresses should be defined mindful of
> the eventual need 
> to transition 48/64 bit addressing.
> 
> Let us not recreate/relive the problems that the mainframe and 68k
> world had when they
> transitioned from their "20-something" bit addresses to 32 bit
> addresses, and programmers
> had use the upper "unused" address bits for non-standard and
> incompatible things. 
> Especially in light of the fact that IEEE1394-1995 is already defined
> as a 64 Bit memory 
> space and OHCI is being defined "after the fact".
> 
> Please don't hesitate to let me know if I'm off-base...
> 
> Regards,
> Oscar.
> 
> 
> At 01:14 PM 5/12/97 -0700, John Nels Fuller wrote:
> >OpenHCI version 1.00 is intended to be a 32-bit adapter so we don't
> want
> >to do these things.  We have given thought to a full 64-bit version
> of
> >OpenHCI but that work is not ready for prime time.
> >
> >However, since software has learned to deal with this kind of
> >restriction before (when systems went from 16 to 32 bits) most OS's
> >already have the tools present to handle this restriction.  And since
> >the majority of transfers are expected to be handled by the physical
> >request/response units, an interim solution to the addressing problem
> >may be a fairly simple enhancement to the physical request/response
> >units to allow them to use more address bits.
> >
> >Nonetheless, my personal opinion is that we should get version 1.00
> out
> >first and start seeing 32-bit PCI cards become available to prove the
> >design before we go out and muddy the waters with greater than 32 bit
> >addressing.
> >
> >> -----Original Message-----
> >> From:	Madhsudan Hans [SMTP:hansm@madmats.esd.sgi.com]
> >> Sent:	Monday, May 12, 1997 12:15 PM
> >> To:	1394ohci-l@austin.ibm.com
> >> Cc:	hansm@madmats.esd.sgi.com
> >> Subject:	DMA Addresses
> >> 
> >> Hi,
> >> 
> >> With processors now able to access up to 64GB of physical memory
> >> (36-bit
> >> addressing) wouldn't it be advantageous to define "extra" bits in
> the
> >> descriptor dataAddress field and the commandPtr registers instead
> of
> >> restricting DMA access to 4GB (32-bit addressing).
> >> 
> >> Thanks.
> >> 
> >> 
> >> -- 
> >> Madhsudan Hans
> >> Silicon Graphics, Inc
> >> Mountain View CA
> >> hansm@sgi.com
> >
> 
> 
> <<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> >>
> Oscar R. Mitchell
>   Engineering Manager, Peripheral Technology Solutions Group
>  Adaptec, Corporation  -:-  "The IEEE-1394 Serial Bus Experts" (tm)
>  Austin Technology Center
>  3925 West Braker Lane -  Suite 425
>  Austin,  Texas  78759
> 
>   (512) 305-0200 Voice
>   (512) 251-5470 Fax  (or 512 305-0212)
> 
>       oscar.mitchell@skipstone.com  -or- oscar@skipstone.com
> 
> URL: http://www.adaptec.com/  -or-  http://www.skipstone.com/
> 
> #include <witty.saying>
> #include <clever.graphic>
> #include <std.disclaimer>
From:	Michael D. Johas Teener - CEO & CTO Firefly Inc [mike@fireflyinc.com]
Sent:	Tuesday, May 13, 1997 9:17 AM
To:	John Nels Fuller
Cc:	1394ohci-l@austin.ibm.com; 'Madhsudan Hans'; 'Oscar R. Mitchell'
Subject:	RE: DMA Addresses

Although I strongly agree with most of what John says in his note, I have a
bit of a nit when he says:

On Mon, May 12, 1997 3:31 PM, John Nels Fuller
<mailto:jfuller@MICROSOFT.com> wrote:
> Additionally, get it out of your mind that this is a
>memory bus!  It is not!  No device should be using addresses that aren't
>implicitly known by virtue of the protocol being used or explicitly
>passed by such a protocol.  Devices do not randomly touch addresses to
>see what is there, if they do they get what they deserve!


It is too a memory bus, but a *virtual* one, just like the one a user-mode
programmer sees. It's OK to play where you've been given permission, but
otherwise you are 1) asking for trouble, and 2) it's not going to work,
anyway.

===================================================================
Michael D. Johas Teener
Chief Executive & Technical Officer, Firefly, Inc.
USA:    269 Mt. Herman Rd. #111, Scotts Valley, CA 95066-4000
        phone: +1-408-461-4901     fax: +1-408-461-1394
Japan:  2-26-8 Takamatsu-cho, Tachikawa, Tokyo 190, Japan
        phone: +81-3-5379-3700     fax: +81-42-523-1808
email:  mike@fireflyinc.com        web: http://www.fireflyinc.com
===================================================================

From:	Madhsudan Hans [hansm@madmats.esd.sgi.com]
Sent:	Tuesday, May 13, 1997 10:39 AM
To:	John Nels Fuller; 'Oscar R. Mitchell'
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: DMA Addresses

On May 12,  3:31pm, John Nels Fuller wrote:
> Subject: RE: DMA Addresses
> The current definition of the PRU says that if the address is >4GB then
> the packet will be delivered to the AR request context for the software
> to deal with.  Additionally, get it out of your mind that this is a
> memory bus!  It is not!  No device should be using addresses that aren't
> implicitly known by virtue of the protocol being used or explicitly
> passed by such a protocol.  Devices do not randomly touch addresses to
> see what is there, if they do they get what they deserve!
>
> As for 64 bitness, we have attempted to ensure that every 32-bit
> register in OpenHCI that contains a host address has a 32-bit reserved
> register adjacent to it that will allow us to expand that address in the
> future.  There are still problems to be solved with taking DMA
> descriptors to 64 bit addressing (we don't like the DBDMA solution, nor
> do we want to expand descriptor commands to 5 quadlets).
>


So what are the real issues (re: 64-bits) with the DBDMA mechanism?

In my opinion, it seems very important to specify a descriptor format that
will not become obsolete in a matter of months. At least reserved fields
in descriptor packets and registers ought to be provided to allow for
expandability and to extend the longevity of the OpenHCI specification.

Perhaps two types of descriptor formats can be designed so that 32-bit
implementations are not burdened with the overhead. A register bit can
 inform the hardware whether 32-bit or 64-bit addressing is being used.
Just my 2 cents.



-- 
Madhsudan Hans
Silicon Graphics, Inc
Mountain View CA
hansm@sgi.com
From:	1394soft-pc@pc.snec.nec.co.jp
Sent:	Wednesday, May 14, 1997 4:39 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Subscribe


Name :     Satoshi Shimmura
Company :NEC Shizuoka,Ltd.
TEL:        +81-537-23-9652
FAX:        +81-537-22-8236
Address:  4-2 SHIMOMATA KAKEGAWA,SHIZUOKA JAPAN  Zip: 436
E-mail  :  1394soft-pc@pc.snec.nec.co.jp
From:	bobf@unix.advansys.com
Sent:	Monday, May 19, 1997 5:16 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Min. number of IR/IT contexts, DMA Summary Table

Isochronous Minimum Number of Contexts
======================================
Can somebody please elaborate the rationale for the minimum number
(4) of Isochronous Transmit and Receive Contexts listed in Table 1-1
on 0.93, p.4. Is there a particular application that the OHCI spec.
is trying to insure that an OHCI HC will be able to support?

If a HC vendor did produce an HC with fewer than the minimum number
of Isochronous Contexts would the OS Vendor's (Microsoft/Apple) OHCI
driver function with the HC? (I know...I'm not trying to get a guarantee
or endorsement for such an HC; I'd like to do risk assesment.) If a
definite answer in either direction can be made I'd appreciate it.
BTW What *is* the best/approved method for an OHCI driver to determine
the number of Isochronous Transmit and Receive contexts supported by
an OHCI HC.

DMA Summary Table
=================
Please confirm a typo in Table 3-5 on 0.93, p. 23. The 4'A and 4'C
tcodes should be removed from Asynchronous Transmit row. These tcodes
are for Isochronous packets.

Bob Frey
bobf@advansys.com
From:	Dream Ku [Dream@via.com.tw]
Sent:	Tuesday, May 20, 1997 12:01 AM
To:	'1394 OHCI Reflector'
Subject:	About OHCI Power Management Status

Hi, All

Do 1394 OHCI have a plan to include the power management registers into
the OHCI specification
in the near feature ? It do so then when is will be available.

 
Dream  Ku
----------------------------------------------------
Software Team, VIA Technologies, Inc.
8F, 533, Chung-Cheng Rd., Hsin-Tien,
Taipei, Taiwan, R.O.C.
Tel : 886-2-2185452
----------------------------------------------------


From:	John Nels Fuller
Sent:	Tuesday, May 20, 1997 2:00 PM
To:	1394OpenHCI; bobf@unix.advansys.com
Subject:	RE: Min. number of IR/IT contexts, DMA Summary Table

Isochronous Contexts
================
We chose 4 for the minimum number of contexts because we wanted to
enable video conferencing as a standard application.  This takes 3
channels in each direction:
	1 to receive local video from camera
	1 to receive local audio from microphone
	1 to receive remote audio/video (compressed)
	1 to transmit local audio/video (compressed)
	1 to transmit remote video (if 1394 display used)
	1 to transmit remote audio (if 1394 speakers used)

We also believe that there are a number of other applications that will
want to use 2 channels in one or the other direction.  Additionally, we
were aware of the development by a number of companies of isochronous
printers that would require 1 transmit channel in order to print, this
would supposedly reduce the cost of laser printers.

Being basically base 2 people we chose 4 as the lowest power of 2 that
encompassed our requirements.

The 'approved' method to determine the number of implemented IR channels
is:
1) clear IsochRx bit in IntMask register
2) write 0xFFFFFFFF to the isoRecvIntMask register
3) read the isoRecvIntMask register, bits that are zero indicate an
unimplemented context.

For the transmit side use the same procedure substituting the IsochTx
and the isoXmitIntMask register.

DMA Summary Table
================
This is not an error, we intentionally want to permit these packets to
be transmitted in the asynchronous transmit request context.  There is
discussion of using asynchronously arbitrated tcode 0xA packets for
asynchronous streams, it is not certain that this will be done but by
allowing it in OpenHCI hardware we are prepared for that eventuality.


> ----------
> From: 	bobf@unix.advansys.com[SMTP:bobf@unix.advansys.com]
> Sent: 	Monday, May 19, 1997 5:16 AM
> To: 	1394ohci-l@austin.ibm.com
> Subject: 	Min. number of IR/IT contexts, DMA Summary Table
> 
> Isochronous Minimum Number of Contexts
> ======================================
> Can somebody please elaborate the rationale for the minimum number
> (4) of Isochronous Transmit and Receive Contexts listed in Table 1-1
> on 0.93, p.4. Is there a particular application that the OHCI spec.
> is trying to insure that an OHCI HC will be able to support?
> 
> If a HC vendor did produce an HC with fewer than the minimum number
> of Isochronous Contexts would the OS Vendor's (Microsoft/Apple) OHCI
> driver function with the HC? (I know...I'm not trying to get a
> guarantee
> or endorsement for such an HC; I'd like to do risk assesment.) If a
> definite answer in either direction can be made I'd appreciate it.
> BTW What *is* the best/approved method for an OHCI driver to determine
> the number of Isochronous Transmit and Receive contexts supported by
> an OHCI HC.
> 
> DMA Summary Table
> =================
> Please confirm a typo in Table 3-5 on 0.93, p. 23. The 4'A and 4'C
> tcodes should be removed from Asynchronous Transmit row. These tcodes
> are for Isochronous packets.
> 
> Bob Frey
> bobf@advansys.com
> 
From:	Josh Collier - SMCC Hardware [Josh.Collier@East.Sun.COM]
Sent:	Tuesday, May 20, 1997 1:50 PM
To:	1394ohci-l@austin.ibm.com
Subject:	LPS & Link On bit

I have noticed the addition of the Link On signal in the Phy/Link interface in
the 1394a 0.08 Spec. I believe OpenHCI should implement a feature to allow 
software interface to these, essentially, power management features. My 
suggestion consists of the addition of a LinkOn interrupt (possibly bit 18 of 
the Interrupt Event and Interrupt Mask registers). This bit is set upon the
assertion of the Link On and the condition that the linkEnable is not set. This 
will cause an interrupt to occur, notifying software of the Link On Packet, 
allowing software to respond by setting the linkEnable bit, and then clearing 
the LinkOn Interrupt. The LPS signal should be controlled by the assertion or 
deassertion of the linkEnable bit.

				Any comments would be appreciated.
				Josh Collier

________________________________________________________________________

 Josh Collier					Tel: 508-442-0471
 Member of Technical Staff			Fax: 508-442-1575
 Workgroup Server Hardware Engineering
 Sun Microsystems Computer Corporation
 Chelmsford, Massachusetts			
________________________________________________________________________
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Tuesday, May 20, 1997 8:50 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: LPS & Link On bit


Text item: 



I don't believe that these pins are even required on the link.  LPS could just 
be tied to Vcc, and LinkOn doesn't have to go anywhere.  An action item in 1394a
is to determine whether these signals are optional / required.

Joe


______________________________ Reply Separator _________________________________
Subject: LPS & Link On bit
Author:  leew@austin.ibm.com at SMTPGATE
Date:    5/20/97 4:50 PM


I have noticed the addition of the Link On signal in the Phy/Link interface in 
the 1394a 0.08 Spec. I believe OpenHCI should implement a feature to allow 
software interface to these, essentially, power management features. My 
suggestion consists of the addition of a LinkOn interrupt (possibly bit 18 of 
the Interrupt Event and Interrupt Mask registers). This bit is set upon the 
assertion of the Link On and the condition that the linkEnable is
not set. This
will cause an interrupt to occur, notifying software of the Link On Packet, 
allowing software to respond by setting the linkEnable bit, and then clearing 
the LinkOn Interrupt. The LPS signal should be controlled by the assertion or 
deassertion of the linkEnable bit.

                    Any comments would be appreciated.
                    Josh Collier

________________________________________________________________________

 Josh Collier                         Tel: 508-442-0471 
 Member of Technical Staff               Fax: 508-442-1575 
 Workgroup Server Hardware Engineering
 Sun Microsystems Computer Corporation 
 Chelmsford, Massachusetts
________________________________________________________________________

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc
Content-MD5: l2mOtx0zx5Qi3Zdsw2/uYg==
Content-Type: TEXT/plain; charset=us-ascii
MIME-Version: 1.0
Message-ID: <libSDtMail.9705201650.26663.jcollier@onsafari>
To: 1394ohci-l@austin.ibm.com
Subject: LPS & Link On bit
Reply-To: Josh Collier - SMCC Hardware <Josh.Collier@East.Sun.COM>
From: Josh Collier - SMCC Hardware <Josh.Collier@East.Sun.COM>
Date: Tue, 20 May 1997 16:50:16 -0400 (EDT)
Received: from onsafari by onsafari.East.Sun.COM (SMI-8.6/SMI-SVR4)
     id QAA01576; Tue, 20 May 1997 16:50:17 -0400
Received: from onsafari.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4)
     id QAA29424; Tue, 20 May 1997 16:50:20 -0400
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3)
     id QAA00105; Tue, 20 May 1997 16:50:09 -0400
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.b
yaddr) with SMTP id OAA05902 for <1394ohci-l@austin.ibm.com>; Tue, 20 May 1997 1
4:05:23 -0700
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by netmail1.austin
.ibm.com (8.6.12/8.6.11) with SMTP id PAA70661 for <1394ohci-l@austin.ibm.com>;
Tue, 20 May 1997 15:50:54 -0500
Received: from netmail1.austin.ibm.com by thalia.fm.intel.com (8.8.4/10.0i); Tue
, 20 May 1997 21:08:52 GMT
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by fmm
ail.fm.intel.com (8.8.5/8.7.3) with ESMTP id OAA20975; Tue, 20 May 1997 14:09:21
 -0700 (PDT)
Return-Path: leew@austin.ibm.com
From:	Josh Collier - SMCC Hardware [Josh.Collier@East.Sun.COM]
Sent:	Wednesday, May 21, 1997 7:04 AM
To:	Joseph_A_Bennett@ccm.fm.intel.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: LPS & Link On bit


It would seem, at least to me, to make sense that Ohci address the issue of 
power management, and having the ability to control the link clock in the 
openHci implementation. This should be a requirement of OHCI?

				Josh Collier
				
________________________________________________________________________

 Josh Collier					Tel: 508-442-0471
 Member of Technical Staff			Fax: 508-442-1575
 Workgroup Server Hardware Engineering
 Sun Microsystems Computer Corporation
 Chelmsford, Massachusetts			
________________________________________________________________________
From:	Yehuda Peled [peled@haifa.vnet]
Sent:	Thursday, May 22, 1997 5:59 AM
To:	1394ohci
Cc:	Etai Adar
Subject:	Receive of PHY packets

What is the reason that the HC need to write the PHY packets to the AR
request 
context ?
Why can't we just discard them ?
What the device driver is going to do with the PHY packets ?
The only meaningful packet is the Link-On packet, that should cause an
interrupt.

Thanks
 Yehuda
-- 
Yehuda Peled
Design engineer - Design center, IBM Israel.
Tel 972-48296149, Fax 972-48296115
E-mail: ypeled@vnet.ibm.com
From:	David Brief [David.Brief@nsc.com]
Sent:	Thursday, May 22, 1997 7:50 AM
To:	1394ohci-l@austin.ibm.com
Subject:	CycleInconsistent Side Effects

After Rereading 9.5.1  that describes the expected software response to
a cycleInconsistent event, I think that the description goes a bit too
far.
As Jerry pointed out below, it is most likely that a cycleInconsistent
event
will occur when two 1394 buses, each with their own IRM, are joined
together.
The proposal to disable cycle matching processing makes complete sense
to me,
but the further requirement to stop ALL running IT contexts contradicts
one of
the goals of the isochronous channel management that was put into
chapter 8 of
the IEEE 1394-1995 document after so much effort - the goal there is
to allow the isochronous channels to continue to work after a reset -
even while 
the bandwidth it being re-verified. 
Figure 9-9 of the OpenHCI spec shows four different contexts which
cleverly 
implement four different policies for use of the isochronous bandwidth
wby using the
skip processing mechanism.
In many cases the iso channel can happily continue to march along
unhindered
as it just doesn't care about any synchronization events - such as is a
channel using
cycle match processing is presumeable interested. 
Just like the use of the skip processing facility is decided based on
the 
type of isochronous channel, so should the channels response to the 
CycleInconsistent event be decided based on the type of isochronous
channel.
I believe that disabling cycle match processing is all that needs to be
guaranteed
by OpenHCI. It should not be necessary to stop any contexts - but it
will be necessary
to modify the cytcleMatch value in all  IT DMA Context Control Registers
where 
cycleMatchEnable is set before the cycleInconsistent interrupt bit is
cleared. 


Jerry Hauck wrote:
> Actually, I believe that cycleInconsistent can and should happen after a
> bus reset if a cycle start is received which is inconsistent with the
> cycleSeconds and cycleCount fields of the cycle timer register.  This is
> particularly important after two 1394 buses (with separate IRM's and cycle counts)
> are joined.  After the ensuing bus reset, only one IRM remains.  OHCI
> devices which were part of the "losing" IRM bus and were configured to perform
> cycleMatch processing now have an issue: the cycle count they are waiting for may
> never come or won't come for a very long time.  The cycleInconsistent event
> notifies software that isochronous contexts relying on cycleMatch must now be
> resynchronized to the new cycle time.  I believe the details of this
> process will be documented in the next release of the OHCI spec.


Proposed change to 9.5.1

In place of:
software must first stop all running contexts .....

modify to :
software must first update the cytcleMatch value in all 
 IT DMA Context Control Registers where cycleMatchEnable is set 
before the cycleInconsistent interrupt bit is cleared.
From:	Patrick_Yu@el.nec.com
Sent:	Thursday, May 22, 1997 12:02 PM
To:	Joseph_A_Bennett@ccm.fm.intel.com; Josh Collier - SMCC Hardware
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re[2]: LPS & Link On bit

For sure, power management is an issue with the host interface that is attached 
to the OHCI block.  How the power management of the OHCI should be supported 
will also be greatly affected by the Power Management Working Group, won't it?

Thanks.

Yours sincerely,
W.S.P. Yu

______________________________ Reply Separator _________________________________
Subject: Re: LPS & Link On bit
Author:  Josh Collier - SMCC Hardware <Josh.Collier@East.Sun.COM> at INTERNET
Date:    5/21/97 7:23 AM


     
It would seem, at least to me, to make sense that Ohci address the issue of 
power management, and having the ability to control the link clock in the 
openHci implementation. This should be a requirement of OHCI?
     
    Josh Collier
     
________________________________________________________________________
     
 Josh Collier     Tel: 508-442-0471
 Member of Technical Staff   Fax: 508-442-1575 
 Workgroup Server Hardware Engineering
 Sun Microsystems Computer Corporation 
 Chelmsford, Massachusetts   
________________________________________________________________________
     
From:	Elsie Wahlig [elsie.wahlig@amd.com]
Sent:	Friday, May 23, 1997 5:45 AM
To:	'1394ohci-l@austin.ibm.com'
Subject:	subscribe

subscribe openHCI 1394ohci-1 reflector
From:	PJohansson@aol.com
Sent:	Friday, May 23, 1997 6:59 AM
To:	peled@haifa.vnet; 1394ohci-l@austin.ibm.com
Cc:	ADAR@haifa.vnet
Subject:	Re: Receive of PHY packets

In a message dated 97-05-22 09:20:30 EDT, peled@haifa.vnet (Yehuda Peled)
writes:

<<What is the reason that the HC need to write the PHY packets to the AR
request 
 context ? Why can't we just discard them ? What the device driver is going
to do with the PHY packets ? The only meaningful packet is the Link-On
packet, that should cause an interrupt.>>

The HC is likely installed a computer which is likely acting as a bus
manager. The bus manager needs the self-ID packets to a) construct the
SPEED_MAP registers, b) construct the TOPOLOGY_MAP registers, c) optimize the
bus-wide gap count and d) locate the isochronous resource manager so that it
may contend for the role of bus manager in the first place.

The last item is also necessary for applications other than the bus manager,
applications that wish to know the location of BANDWIDTH_AVAILABLE and
CHANNELS_AVAILABLE.

As you can see, more than the link-on packet is meaningful and should be
captured by OpenHCI. You'll eventually want to catch the P1394a "ping"
packet, as well...

Regards,

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com
From:	John Nels Fuller
Sent:	Friday, May 23, 1997 5:32 PM
To:	'Diana Klashman (Sun)'
Cc:	'1394OpenHCI'
Subject:	IRcontextMatch register

It has been brought to my attention that the captions for figure 10-6
and table 10-4 incorrectly state that the IRcontextMatch register is a
"set and clear" register.  This is not the case, this register is an
ordinary read/write register and has only one address.

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (425) 703-3863
Fax: (425) 93 MSFAX

From:	yokada@flab.fujitsu.co.jp
Sent:	Saturday, May 24, 1997 12:06 AM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe me to OpenHCI reflector

Dear

I would like you to subscribe me to OpenHCI reflector.

Name:Yoshiyuki Okada
Company: Fujitsu Lab.
E-mail:yokada@flab.fujitsu.co.jp

Thank you.
Regards.

***************************************************************
Yoshiyuki Okada

I/O Systems Laboratory, Peripheral Systems Laboratories,
Fujitsu Laboratories Ltd.

10-1 Morinosato-wakamiya, Atsugi, 243-01, Kanagawa, Japan
TEL:+81-462-50-8223, Fax:+81-462-48-3233
E-mail: yokada@flab.fujitsu.co.jp
******************************
??????  ????????????? ??????  
                               ???? (Yoshiyuki Okada)
                          E-mail: yokada@flab.fujitsu.co.jp
                          NIFTY : MAE01350
                          ??  : 0462-48-3111, ??)7121-3330
             FAX   : 0462-48-3233, ??)7121-4991
                          ?? : 0462-50-8223
From:	Diana.Klashman@East.Sun.COM
Sent:	Monday, May 26, 1997 7:40 AM
To:	John Nels Fuller
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: IRcontextMatch register

Good catch.  I'll make the fix.

Diana


>From jfuller@MICROSOFT.com Fri May 23 20:34:13 1997
>From: John Nels Fuller <jfuller@MICROSOFT.com>
>
>It has been brought to my attention that the captions for figure 10-6
>and table 10-4 incorrectly state that the IRcontextMatch register is a
>"set and clear" register.  This is not the case, this register is an
>ordinary read/write register and has only one address.
>
>_____________________
>John Nels Fuller
>Software Design Engineer, Windows NT
>Microsoft Corporation
>One Microsoft Way
>Redmond, WA   98052-6399
>Voice: (425) 703-3863
>Fax: (425) 93 MSFAX
>


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From:	Yehuda Peled [peled@haifa.vnet]
Sent:	Monday, May 26, 1997 8:09 AM
To:	PJohansson@aol.com
Cc:	peled%haifa.RSCS@HAIFASCD.HAIFA.IBM.COM; 1394ohci-l@austin.ibm.com; ADAR%haifa.RSCS@HAIFASCD.HAIFA.IBM.COM
Subject:	Re: Receive of PHY packets

Peter,
See my comments below.

Thanks
 Yehuda

PJohansson@AOL.COM wrote:
> 
> In a message dated 97-05-22 09:20:30 EDT, peled@haifa.vnet (Yehuda Peled)
> writes:
> 
> <<What is the reason that the HC need to write the PHY packets to the AR
> request
>  context ? Why can't we just discard them ? What the device driver is going
> to do with the PHY packets ? The only meaningful packet is the Link-On
> packet, that should cause an interrupt.>>
> 
> The HC is likely installed a computer which is likely acting as a bus
> manager. The bus manager needs the self-ID packets to a) construct the
> SPEED_MAP registers, b) construct the TOPOLOGY_MAP registers, c) optimize the
> bus-wide gap count and d) locate the isochronous resource manager so that it
> may contend for the role of bus manager in the first place.
> 
> The last item is also necessary for applications other than the bus manager,
> applications that wish to know the location of BANDWIDTH_AVAILABLE and
> CHANNELS_AVAILABLE.
> 

There is no question that the HC must forward the self ID packets 
(received during bus reset) to the host memory.
My question is on PHY packets, that arrived not during a 1394 bus 
reset.

> As you can see, more than the link-on packet is meaningful and should be
> captured by OpenHCI. You'll eventually want to catch the P1394a "ping"
> packet, as well...
> 

As I understand it the ping time is calculated by the PHY. 
The device driver does not need to receive the ping packet. 
It just need to read the "ping time" value from the PHY register.


> Regards,
> 
> Peter Johansson
> 
> Congruent Software, Inc.
> 3998 Whittle Avenue
> Oakland, CA  94602
> 
> (510) 531-5472
> (510) 531-2942 FAX
> 
> pjohansson@aol.com

-- 
Yehuda Peled
Design engineer - Design center, IBM Israel.
Tel 972-48296149, Fax 972-48296115
E-mail: ypeled@vnet.ibm.com
From:	Steve G. Kukla [stevek@aspera.com]
Sent:	Sunday, May 25, 1997 5:01 PM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe OpenHCI

subscribe Steve Kukla

Steve G. Kukla
President
The Aspera Group
6510 N. Spring Mill Rd.
Indianapolis, IN  46260
(317)254-8354
(317)254-8384 FAX
stevek@aspera.com
From:	John Nels Fuller
Sent:	Monday, May 26, 1997 11:26 PM
To:	Peter Johansson (1394); Yehuda Peled
Cc:	peled%haifa.RSCS@HAIFASCD.HAIFA.IBM.COM; 1394ohci-l@austin.ibm.com; ADAR%haifa.RSCS@HAIFASCD.HAIFA.IBM.COM
Subject:	RE: Receive of PHY packets

Two points on P1394a "ping" packets:

1) at the last P1394a meeting the ping timer was moved to the link (that
way only bus manager capable nodes need it).

2) the contents of the ping response may be of interest to the s/w,
especially if it is from one's own PHY (which, last I heard, is
allowed).

> ----------
> From: 	Yehuda Peled[SMTP:peled@haifa.vnet]
> Sent: 	Monday, May 26, 1997 8:09 AM
> To: 	PJohansson@aol.com
> Cc: 	peled%haifa.RSCS@HAIFASCD.HAIFA.IBM.COM;
> 1394ohci-l@austin.ibm.com; ADAR%haifa.RSCS@HAIFASCD.HAIFA.IBM.COM
> Subject: 	Re: Receive of PHY packets
> 
> Peter,
> See my comments below.
> 
> Thanks
>  Yehuda
> 
> PJohansson@AOL.COM wrote:
> > 
> > In a message dated 97-05-22 09:20:30 EDT, peled@haifa.vnet (Yehuda
> Peled)
> > writes:
> > 
> > <<What is the reason that the HC need to write the PHY packets to
> the AR
> > request
> >  context ? Why can't we just discard them ? What the device driver
> is going
> > to do with the PHY packets ? The only meaningful packet is the
> Link-On
> > packet, that should cause an interrupt.>>
> > 
> > The HC is likely installed a computer which is likely acting as a
> bus
> > manager. The bus manager needs the self-ID packets to a) construct
> the
> > SPEED_MAP registers, b) construct the TOPOLOGY_MAP registers, c)
> optimize the
> > bus-wide gap count and d) locate the isochronous resource manager so
> that it
> > may contend for the role of bus manager in the first place.
> > 
> > The last item is also necessary for applications other than the bus
> manager,
> > applications that wish to know the location of BANDWIDTH_AVAILABLE
> and
> > CHANNELS_AVAILABLE.
> > 
> 
> There is no question that the HC must forward the self ID packets 
> (received during bus reset) to the host memory.
> My question is on PHY packets, that arrived not during a 1394 bus 
> reset.
> 
> > As you can see, more than the link-on packet is meaningful and
> should be
> > captured by OpenHCI. You'll eventually want to catch the P1394a
> "ping"
> > packet, as well...
> > 
> 
> As I understand it the ping time is calculated by the PHY. 
> The device driver does not need to receive the ping packet. 
> It just need to read the "ping time" value from the PHY register.
> 
> 
> > Regards,
> > 
> > Peter Johansson
> > 
> > Congruent Software, Inc.
> > 3998 Whittle Avenue
> > Oakland, CA  94602
> > 
> > (510) 531-5472
> > (510) 531-2942 FAX
> > 
> > pjohansson@aol.com
> 
> -- 
> Yehuda Peled
> Design engineer - Design center, IBM Israel.
> Tel 972-48296149, Fax 972-48296115
> E-mail: ypeled@vnet.ibm.com
> 
From:	Dream Ku [Dream@via.com.tw]
Sent:	Tuesday, May 27, 1997 3:34 AM
To:	'1394 OHCI Reflector'
Subject:	GUID interface question


The OHCI 0.93 in P5 describes that the 1394 64-bit "node_unique_ID" may
be loaded following a hardware reset if the serialROM bit is set to one.
But there is no serialROM bit in the Version
Register but only GUID_ROM in the P29. In the Table 5-1 the description
of GUID_ROM is 
"The bus_info_block will be automatically loaded on the hardware reset."

I think that the "node_unique_ID" in the P5 will be right and the
serialROM bit should be named to 
GUID_ROM in the P5.	

Dream  Ku
----------------------------------------------------------------
Software Team, VIA Technologies, Inc.
8F, 533, Chung-Cheng Rd., Hsin-Tien,
Taipei, Taiwan, R.O.C.
Tel : 886-2-2185452    Fax: 886-2-2185453


From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Tuesday, May 27, 1997 2:53 PM
To:	1394ohci-l@austin.ibm.com
Subject:	max_rec fieldin Bus Options register


In section 5.5.4, Table 5-8, the bit description for max_rec states that:

    "For a hardware reset, max_rec is set to the maximum value supported by the 
    implementation, 512 or greater.  For a soft reset, max_rec is not changed."
    
What is hardware supposed to use to determine this value -- transmit FIFO size? 
What would an OHCI driver do differently if one OHCI controller put 2048, and 
another put 1024?
From:	Kazu-Yoshi KIKUTA [kikuta@mos.fvd.fujitsu.co.jp]
Sent:	Tuesday, May 27, 1997 4:57 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Registration form

Dear reflector
 Let me add to the OHCI refrector, please. I'm already 1394TA member. 

 Name      Kazu-Yoshi Kikuta
 title     Project Manager
 Company   Fujitsu VLSI Limited
 Address   2-1844-2 Kozoji Kasugai Aichi 487, Japan
 Tel       +81-568-51-8078
 Fax       +81-568-51-7802
 e-mail    kikuta@mos.fvd.fujitsu.co.jp

                                                      Best Regards
                                                      K. Kikuta 
From:	Jaideep Bhatia [jaideep@wipinfo.soft.net]
Sent:	Tuesday, May 27, 1997 8:33 PM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

Dear administrator for 1394ohci-l reflector,
	Kinkdly add my email address to the  1394ohci-l reflector.

	jaideep@wipinfo.soft.net

	Thanks.

Regards,

Jaideep Bhatia
Senior Engineer, R&D Hardware
Wipro Infotech Limited
88, M G Road
Bangalore 560001
India

91-80- 5588422,5588667	Ext:553
jaideep@wipinfo.soft.net
From:	dany@flab.fujitsu.co.jp
Sent:	Wednesday, May 28, 1997 1:29 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Please Subscribe 1394-OHCI reflector

Dear sir:

I am working on developing IO interface. Recently I found the
1394-OHCI reflector on 1394TA WWW Page. Please subscribe these.  So I
send you E-mail with my information. I look forward to your reply.

  Name:          : Akira Karasudani
  Company        : I/O Systems Lab.
                   FUJITSU LABORATORIES LTD.
  E-mail Address : dany@flab.fujitsu.co.jp
From:	yehiel engel [YENGEL@HAIFASC3.HAIFA.IBM.COM]
Sent:	Wednesday, May 28, 1997 4:34 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Unsubscribe.

Hello
please unsubscribe me from this reflector.

Regards
Yehiel Engel
From:	PJohansson@aol.com
Sent:	Wednesday, May 28, 1997 11:12 AM
To:	ypeled@vnet.ibm.com
Cc:	peled%haifa.RSCS@haifascd.haifa.ibm.com; 1394ohci-l@austin.ibm.com; ADAR%haifa.RSCS@haifascd.haifa.ibm.com
Subject:	Re: Receive of PHY packets

In a message dated 97-05-26 11:07:33 EDT, ypeled@VNET.IBM.COM (Yehuda Peled)
writes:

<<As I understand it the ping time is calculated by the PHY. The device
driver does not need to receive the ping packet. It just need to read the
"ping time" value from the PHY register.>>

There is still ongoing discussion in P1394a whether to locate the timer in
the PHY or in the link. One argument advanced for placing the timer in the
link is that ACK packets could then be timed by the link---even from older
PHY's that do not support "pinging". In any case, it's not yet settled where
to expect the timer.

Regards,

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com
From:	DavidW@bangate.compaq.com
Sent:	Thursday, May 29, 1997 9:38 AM
To:	1394ohci-l@austin.ibm.com
Subject:	re: max_rec fieldin Bus Options register

Joe,

Presumably, this value will be loaded in a manner similar to the way the GUID 
is loaded.  The people who build the system/add-in are supposed to know how 
the HC will behave and set the value accordingly.  Although FIFO sizes will 
affect the value, they will not be the only factor.  In general, the packet 
size should be larger than the FIFO sizes.

Drivers will use the max_rec size in several ways.  In SBP it will be used to 
set the maximum packet that the drive will try to transfer (this is either a 
parameter in the ORB or is determined by the page size.

David Wooten


Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com> Wrote:
| 
| 
| In section 5.5.4, Table 5-8, the bit description for max_rec states that:
| 
|     "For a hardware reset, max_rec is set to the maximum value supported by 
the 
|     implementation, 512 or greater.  For a soft reset, max_rec is not 
changed."
|     
| What is hardware supposed to use to determine this value -- transmit FIFO 
size? 
| What would an OHCI driver do differently if one OHCI controller put 2048, 
and 
| another put 1024?
| 
| 
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Thursday, May 29, 1997 10:52 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Bus Number reset with a Bus Reset?

---------------------------- Forwarded with Changes ---------------------------
From: dicks@lsi.sel.sony.com at SMTPGATE
Date: 5/29/97 9:56AM
To: Jerry Hauck at RNBCCM33
*cc: p1394.bridges@Sun.COM at SMTPGATE
Subject: Re: Bus Number reset with a Bus Reset?
-------------------------------------------------------------------------------
     Based on the following mail thread, I believe that the busNumber field 
     in the Node Identification and Status register should be reset to 
     10'h3FF on a 1394 bus reset.  The 0.93 draft makes no mention of bus 
     reset for this field.
     
     Specific edits required:
        - Section 5.9 for the description of the busNumber field
        - Annex C, list 10'h3FF as bus reset value for busNumber within 
        NodeID on page 137.
        
     
     Thanks
     Jerry Hauck
     Intel Corp.
     (408) 765-5528
     Jerry_Hauck@ccm.sc.intel.com
        


______________________________ Forward Header __________________________________
Subject: Re: Bus Number reset with a Bus Reset?
Author:  dicks@lsi.sel.sony.com at SMTPGATE
Date:    5/29/97 9:56 AM


Hi Jerry,
     
Thanks for the question.  This is something we addressed a few months ago, 
because the 1394-1995 spec. does not make it real obvious.
     
The bus_id SHOULD be reset to 3FF on a bus reset.  This is not explicitly 
stated in the description of this field in section 8.3.2.2.3 of the 
1394-1995 document, but it is derived from the fact that the "initial value" 
of the field is 3FF, and a few pages earlier at the end of section 8.3.2.1 
it says that unless stated otherwise for a CSR, a bus reset causes a return 
to initial values.
     
In fact, the circumstance that you described can only be properly handled if 
all devices reset their bus_id on a bus reset.
     
Regards,
Dick Scheel
     
At 05:18 PM 5/28/97 PDT, Jerry Hauck wrote: 
>     Bridge folks,
>
>     Once configured, a link performs address matching against bus number 
>     3ff and a second bus number configured by the bridge manager.  If a
>     bus reset occurs, should the configurable bus number used by the link 
>     be reset as well??
>
>     I'm imagining a scenario where two previously independent 1394 bridged 
>     networks get joined and duplicate bus numbers exist.  Is it important 
>     that links automatically clear their bus numbers, or are there other
>     mechanisms that ensure that the bridge manager will hand out new bus 
>     numbers before problems with duplication arise.
>
>     The reason I'm specifically asking is that while OHCI assures that the 
>     attached link's nodeNumber is properly marked as stale after a bus
>     reset (and before the PHY issues a new one), the busNumber field
>     remains unchanged in hardware.  Before asking for an OHCI spec change, 
>     I wanted to understand if the problem was real.
>
>     Thanks for your help,
>     Jerry Hauck
>     Intel Corp.
>     (408) 765-5528
>     jerry_hauck@ccm.sc.intel.com
>
>
================================================================= 
| Dick Scheel                   | Mgr, Comm. Architecture       | 
| Sony US Research Labs         | Tel: (408) 955-4295           | 
| LSI Systems Laboratory        | Fax: (408) 955-5180           | 
| 3300 Zanker Rd.   M/S SJ3D3   | email: dicks@lsi.sel.sony.com | 
| San Jose, CA  95134-1940      | O-                            | 
=================================================================
From:	DavidW@bangate.compaq.com
Sent:	Thursday, May 29, 1997 12:10 PM
To:	1394ohci-l@austin.ibm.com
Subject:	re: CycleInconsistent Side Effects

Again, the problem is _not_ in setting the cycle match registers to values 
that are appropriate for the new cycle start values.  The problem is getting 
the host side cycle number (the one that is used for cycle matching) 
consistent with the new cycle number on the link side.  The host side is 
running isochronously with the link side and has a cycle number that is 
different from that of the link side.  If we don't stop iso transmit at some 
point after we get a cycle inconsistent, then we will never know exactly what 
the offset is between the host and link side.


We are still looking for a low cost way to resynchronize w/o stopping iso 
transmit.  Until we have one, the plan is that SW will stop all iso transmits 
before trying to do cycle matching after a cycle inconsistent.

David Wooten


David Brief <David.Brief@nsc.com> Wrote:
| 
| After Rereading 9.5.1  that describes the expected software response to
| a cycleInconsistent event, I think that the description goes a bit too far.
| As Jerry pointed out below, it is most likely that a cycleInconsistent event
| will occur when two 1394 buses, each with their own IRM, are joined 
together.
| The proposal to disable cycle matching processing makes complete sense to 
me,
| but the further requirement to stop ALL running IT contexts contradicts one 
of
| the goals of the isochronous channel management that was put into chapter 8 
of
| the IEEE 1394-1995 document after so much effort - the goal there is
| to allow the isochronous channels to continue to work after a reset - even 
while 
| the bandwidth it being re-verified. 
|
| Figure 9-9 of the OpenHCI spec shows four different contexts which cleverly 
| implement four different policies for use of the isochronous bandwidth wby 
using the
| skip processing mechanism.
|
| In many cases the iso channel can happily continue to march along unhindered
| as it just doesn't care about any synchronization events - such as is a 
channel using
| cycle match processing is presumeable interested. 
|
| Just like the use of the skip processing facility is decided based on the 
| type of isochronous channel, so should the channels response to the 
| CycleInconsistent event be decided based on the type of isochronous channel.
| I believe that disabling cycle match processing is all that needs to be 
guaranteed
| by OpenHCI. It should not be necessary to stop any contexts - but it will be 
necessary
| to modify the cytcleMatch value in all  IT DMA Context Control Registers 
where 
| cycleMatchEnable is set before the cycleInconsistent interrupt bit is 
cleared. 
| 
| 
| Jerry Hauck wrote:
| > Actually, I believe that cycleInconsistent can and should happen after a
| > bus reset if a cycle start is received which is inconsistent with the
| > cycleSeconds and cycleCount fields of the cycle timer register.  This is
| > particularly important after two 1394 buses (with separate IRM's and cycle 
counts)
| > are joined.  After the ensuing bus reset, only one IRM remains.  OHCI
| > devices which were part of the "losing" IRM bus and were configured to 
perform
| > cycleMatch processing now have an issue: the cycle count they are waiting 
for may
| > never come or won't come for a very long time.  The cycleInconsistent 
event
| > notifies software that isochronous contexts relying on cycleMatch must now 
be
| > resynchronized to the new cycle time.  I believe the details of this
| > process will be documented in the next release of the OHCI spec.
| 
| 
| Proposed change to 9.5.1
| 
| In place of:
| software must first stop all running contexts .....
| 
| modify to :
| software must first update the cytcleMatch value in all 
|  IT DMA Context Control Registers where cycleMatchEnable is set 
| before the cycleInconsistent interrupt bit is cleared.
| 
From:	zung [zung@via.com.tw]
Sent:	Friday, May 30, 1997 3:29 PM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

Subscribe

	~~~~~~~~~~~~~~~~~~~~~~~~~~ 
	Jung-Tsan Hsu
	ASIC engineer
	VIA Technology, INC.
	E-mail:zung@via.com.tw
	TEL:886-2-218-5452 EXT:304
	FAX:886-2-218-5453
	~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Friday, May 30, 1997 1:59 PM
To:	P1394@sun.com; 1394ohci-l@austin.ibm.com
Subject:	"Loose Asynchronous" vs "Loose Isochronous"

     I believe discussions regarding "asynchronous streams" and lost cycle 
     start packets have led both OHCI and P1394a to a "loose isochronous" 
     interpretation which allows the link to receive isochronous packets 
     within the asynchronous period.  (In fact, OHCI mandates "loose 
     isochronous" implementations.)
     
     But what behavior should be specified if an otherwise valid 
     asynchronous packet is received during the isochronous period (i.e., 
     between cycle start and the first subaction gap)?  Assuming the specs 
     are currently silent on the point, I think there are two basic 
     options:
     
     1) Continue to say nothing in the specifications ... the reception of 
     an asynchronous packet during the isochronous period is clearly the 
     sign of a broken bus.  Don't force implementations to check or 
     correct.
     
     2) Require that links NOT issue an acknowledge packet.  (Issuing an 
     acknowledge would likely interfere with isochronous arbitration.)   In 
     the case of OHCI, the link could pass the packet up the stack with an 
     event code of ack_missing.
     
     Does anyone feel that the packet (assuming it passes CRC) must be 
     accepted by the link and processed as if received during the 
     asynchronous period (with the exception of the ack generation).
     
     Feedback requested,
     Jerry Hauck
     Intel Corp.
     jerry_hauck@ccm.sc.intel.com
From:	John Nels Fuller
Sent:	Friday, May 30, 1997 5:16 PM
To:	'Jerry Hauck'; P1394@sun.com; 1394ohci-l@austin.ibm.com
Subject:	RE: "Loose Asynchronous" vs "Loose Isochronous"

Jerry,

The spec is not silent on this subject.  I believe it says that if an
async packet is seen during the iso period then the iso period ends and
the async packet is received normally.

I don't know if this is the desired behavior.  It is an interesting idea
to schedule "async" packets during iso in order to have a private iso
stream.  However, in order to avoid having to put on flame retardant, I
will quickly say that I'm not proposing we make a change but I'm just
trying to say that if you don't like what is currently spec'd there are
a lot more possibilities than the two you list.

_____________________
John Nels Fuller
Software Design Engineer, Windows NT
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (425) 703-3863
Fax: (425) 93 MSFAX


> -----Original Message-----
> From:	Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com]
> Sent:	Friday, May 30, 1997 1:59 PM
> To:	P1394@Sun.COM; 1394ohci-l@austin.ibm.com
> Subject:	"Loose Asynchronous" vs "Loose Isochronous"
> 
>      I believe discussions regarding "asynchronous streams" and lost
> cycle 
>      start packets have led both OHCI and P1394a to a "loose
> isochronous" 
>      interpretation which allows the link to receive isochronous
> packets 
>      within the asynchronous period.  (In fact, OHCI mandates "loose 
>      isochronous" implementations.)
>      
>      But what behavior should be specified if an otherwise valid 
>      asynchronous packet is received during the isochronous period
> (i.e., 
>      between cycle start and the first subaction gap)?  Assuming the
> specs 
>      are currently silent on the point, I think there are two basic 
>      options:
>      
>      1) Continue to say nothing in the specifications ... the
> reception of 
>      an asynchronous packet during the isochronous period is clearly
> the 
>      sign of a broken bus.  Don't force implementations to check or 
>      correct.
>      
>      2) Require that links NOT issue an acknowledge packet.  (Issuing
> an 
>      acknowledge would likely interfere with isochronous arbitration.)
> In 
>      the case of OHCI, the link could pass the packet up the stack
> with an 
>      event code of ack_missing.
>      
>      Does anyone feel that the packet (assuming it passes CRC) must be
> 
>      accepted by the link and processed as if received during the 
>      asynchronous period (with the exception of the ack generation).
>      
>      Feedback requested,
>      Jerry Hauck
>      Intel Corp.
>      jerry_hauck@ccm.sc.intel.com
From:	Pujol, Matt [MPUJOL@FTCMPD4TH.CO.SYMBIOS.COM]
Sent:	Friday, May 30, 1997 5:07 PM
To:	P1394; 1394ohci-l; Jerry Hauck
Subject:	RE: "Loose Asynchronous" vs "Loose Isochronous"


Allowing async packets during the immediate period following a cycle   
start event means that the guarantee of bus time to isoc talkers is no   
longer valid.  The bus architecture then mutates into a collection of   
various acknowledged and unacknowledged packet types with an essentially   
meaningless cycle start packet type.

Let's not forget that the loose isochronous is a valiant attempt to solve   
the lack of a nice asynch broadcast feature.

I'd have to vote for keeping the isoc bus phase sacred.

=====================================================================
Matt Pujol                                       (970) 223-5100 x9816
1394 Systems/Applications                      matt.pujol@symbios.com
Symbios Logic
Fort Collins, CO
=====================================================================

 ----------
From:  Jerry Hauck
Sent:  Friday, May 30, 1997 1:59 PM
To:  P1394; 1394ohci-l
Subject:  "Loose Asynchronous" vs "Loose Isochronous"

     I believe discussions regarding "asynchronous streams" and lost   
cycle
     start packets have led both OHCI and P1394a to a "loose isochronous"   

     interpretation which allows the link to receive isochronous packets
     within the asynchronous period.  (In fact, OHCI mandates "loose
     isochronous" implementations.)
       

     But what behavior should be specified if an otherwise valid
     asynchronous packet is received during the isochronous period (i.e.,   

     between cycle start and the first subaction gap)?  Assuming the   
specs
     are currently silent on the point, I think there are two basic
     options:
       

     1) Continue to say nothing in the specifications ... the reception   
of
     an asynchronous packet during the isochronous period is clearly the
     sign of a broken bus.  Don't force implementations to check or
     correct.
       

     2) Require that links NOT issue an acknowledge packet.  (Issuing an
     acknowledge would likely interfere with isochronous arbitration.)   
  In
     the case of OHCI, the link could pass the packet up the stack with   
an
     event code of ack_missing.
       

     Does anyone feel that the packet (assuming it passes CRC) must be
     accepted by the link and processed as if received during the
     asynchronous period (with the exception of the ack generation).
       

     Feedback requested,
     Jerry Hauck
     Intel Corp.
     jerry_hauck@ccm.sc.intel.com
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Friday, May 30, 1997 6:02 PM
To:	John Nels Fuller; P1394@sun.com; 1394ohci-l@austin.ibm.com
Subject:	Re[2]: "Loose Asynchronous" vs "Loose Isochronous"

     John,
     
     Thanks for the response.  Do you (or does someone) have a reference in 
     a particular specification?  The L10:L0 transition in 6.3.3 of the 
     1995 spec does not allow the isochronous period to end with reception 
     of an asynchronous packet as you suggest, so I'm still hunting.  Any 
     help appreciated.
     
     Jerry


______________________________ Reply Separator _________________________________
Subject: RE: "Loose Asynchronous" vs "Loose Isochronous"
Author:  jfuller@MICROSOFT.com at SMTPGATE
Date:    5/30/97 5:15 PM


Jerry,
     
The spec is not silent on this subject.  I believe it says that if an 
async packet is seen during the iso period then the iso period ends and 
the async packet is received normally.
     
I don't know if this is the desired behavior.  It is an interesting idea 
to schedule "async" packets during iso in order to have a private iso 
stream.  However, in order to avoid having to put on flame retardant, I 
will quickly say that I'm not proposing we make a change but I'm just 
trying to say that if you don't like what is currently spec'd there are 
a lot more possibilities than the two you list.
     
_____________________
John Nels Fuller
Software Design Engineer, Windows NT 
Microsoft Corporation
One Microsoft Way
Redmond, WA   98052-6399
Voice: (425) 703-3863
Fax: (425) 93 MSFAX
     
     
> -----Original Message-----
> From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
> Sent:     Friday, May 30, 1997 1:59 PM
> To:     P1394@Sun.COM; 1394ohci-l@austin.ibm.com
> Subject:     "Loose Asynchronous" vs "Loose Isochronous" 
>
>      I believe discussions regarding "asynchronous streams" and lost 
> cycle
>      start packets have led both OHCI and P1394a to a "loose 
> isochronous"
>      interpretation which allows the link to receive isochronous 
> packets
>      within the asynchronous period.  (In fact, OHCI mandates "loose 
>      isochronous" implementations.)
>
>      But what behavior should be specified if an otherwise valid
>      asynchronous packet is received during the isochronous period 
> (i.e.,
>      between cycle start and the first subaction gap)?  Assuming the 
> specs
>      are currently silent on the point, I think there are two basic 
>      options:
>
>      1) Continue to say nothing in the specifications ... the 
> reception of
>      an asynchronous packet during the isochronous period is clearly 
> the
>      sign of a broken bus.  Don't force implementations to check or 
>      correct.
>
>      2) Require that links NOT issue an acknowledge packet.  (Issuing 
> an
>      acknowledge would likely interfere with isochronous arbitration.) 
> In
>      the case of OHCI, the link could pass the packet up the stack 
> with an
>      event code of ack_missing.
>
>      Does anyone feel that the packet (assuming it passes CRC) must be 
>
>      accepted by the link and processed as if received during the
>      asynchronous period (with the exception of the ack generation). 
>
>      Feedback requested,
>      Jerry Hauck
>      Intel Corp.
>      jerry_hauck@ccm.sc.intel.com
From:	John Nels Fuller
Sent:	Friday, May 30, 1997 6:54 PM
To:	'Jerry Hauck'; P1394@sun.com; 1394ohci-l@austin.ibm.com
Subject:	RE: Re[2]: "Loose Asynchronous" vs "Loose Isochronous"

Jerry,

I can't remember who told me that this was the behavior, but it seems to
disagree with the behavior described in the description of the L13:L10
transition.

> -----Original Message-----
> From:	Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com]
> Sent:	Friday, May 30, 1997 6:02 PM
> To:	John Nels Fuller; P1394@Sun.COM; 1394ohci-l@austin.ibm.com
> Subject:	Re[2]: "Loose Asynchronous" vs "Loose Isochronous"
> 
>      John,
>      
>      Thanks for the response.  Do you (or does someone) have a
> reference in 
>      a particular specification?  The L10:L0 transition in 6.3.3 of
> the 
>      1995 spec does not allow the isochronous period to end with
> reception 
>      of an asynchronous packet as you suggest, so I'm still hunting.
> Any 
>      help appreciated.
>      
>      Jerry
> 
> 
> ______________________________ Reply Separator
> _________________________________
> Subject: RE: "Loose Asynchronous" vs "Loose Isochronous"
> Author:  jfuller@MICROSOFT.com at SMTPGATE
> Date:    5/30/97 5:15 PM
> 
> 
> Jerry,
>      
> The spec is not silent on this subject.  I believe it says that if an 
> async packet is seen during the iso period then the iso period ends
> and 
> the async packet is received normally.
>      
> I don't know if this is the desired behavior.  It is an interesting
> idea 
> to schedule "async" packets during iso in order to have a private iso 
> stream.  However, in order to avoid having to put on flame retardant,
> I 
> will quickly say that I'm not proposing we make a change but I'm just 
> trying to say that if you don't like what is currently spec'd there
> are 
> a lot more possibilities than the two you list.
>      
> _____________________
> John Nels Fuller
> Software Design Engineer, Windows NT 
> Microsoft Corporation
> One Microsoft Way
> Redmond, WA   98052-6399
> Voice: (425) 703-3863
> Fax: (425) 93 MSFAX
>      
>      
> > -----Original Message-----
> > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
> > Sent:     Friday, May 30, 1997 1:59 PM
> > To:     P1394@Sun.COM; 1394ohci-l@austin.ibm.com
> > Subject:     "Loose Asynchronous" vs "Loose Isochronous" 
> >
> >      I believe discussions regarding "asynchronous streams" and lost
> 
> > cycle
> >      start packets have led both OHCI and P1394a to a "loose 
> > isochronous"
> >      interpretation which allows the link to receive isochronous 
> > packets
> >      within the asynchronous period.  (In fact, OHCI mandates "loose
> 
> >      isochronous" implementations.)
> >
> >      But what behavior should be specified if an otherwise valid
> >      asynchronous packet is received during the isochronous period 
> > (i.e.,
> >      between cycle start and the first subaction gap)?  Assuming the
> 
> > specs
> >      are currently silent on the point, I think there are two basic 
> >      options:
> >
> >      1) Continue to say nothing in the specifications ... the 
> > reception of
> >      an asynchronous packet during the isochronous period is clearly
> 
> > the
> >      sign of a broken bus.  Don't force implementations to check or 
> >      correct.
> >
> >      2) Require that links NOT issue an acknowledge packet.
> (Issuing 
> > an
> >      acknowledge would likely interfere with isochronous
> arbitration.) 
> > In
> >      the case of OHCI, the link could pass the packet up the stack 
> > with an
> >      event code of ack_missing.
> >
> >      Does anyone feel that the packet (assuming it passes CRC) must
> be 
> >
> >      accepted by the link and processed as if received during the
> >      asynchronous period (with the exception of the ack generation).
> 
> >
> >      Feedback requested,
> >      Jerry Hauck
> >      Intel Corp.
> >      jerry_hauck@ccm.sc.intel.com
From:	Hugh Curley [hcurley@indra.com]
Sent:	Saturday, May 31, 1997 7:47 PM
To:	'1394ohci-l@austin.ibm.com'
Subject:	Subscribe

Subscribe hcurley@indra.com

Thank you
Hugh Curley
From:	DavidW@bangate.compaq.com
Sent:	Monday, June 02, 1997 7:31 AM
To:	P1394@sun.com; 1394ohci-l@austin.ibm.com
Subject:	re: RE: Re[2]: "Loose Asynchronous" vs "Loose Isochronous"

I think that Jerry's proposal that the link not send an ACK if an asynch 
packet is received in the iso interval is the only one that keeps us out of 
trouble.  Depending on the speed of the asynch packet, some device may not see 
the asynch packet or the ACK so not all devices would end the iso interval.  
They will stay in iso mode and continue with normal iso arbitration.  So, I 
think that a device that tries to ACK an asynch packet during the iso interval 
will screw up the iso arbitration and things could really get screwed up if we 
don't require that the ACK be suppressed because an ACK can lead to triggering 
 a node trying to do ack accelerated or flyby arbitration.  Now, it may be 
that we want a node to suppress any iso transmit when it sees an asynch packet 
go by (not a proposal) but it does not mean that the iso interval ends.  Iso 
interval still lasts until the subaction gap is seen.

If we are going to add ack accelerations, we should also make a statement 
about not acking during the iso interval and that an asynch packet does not 
end the iso interval so no ack accelerations are triggered even if an ack is 
seen during the iso interval. (I wanted to make that a longer, run on sentence 
but I couldn't think of anything more to add.)

David Wooten


John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
| 
| Jerry,
| 
| I can't remember who told me that this was the behavior, but it seems to
| disagree with the behavior described in the description of the L13:L10
| transition.
| 
| > -----Original Message-----
| > From:	Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com]
| > Sent:	Friday, May 30, 1997 6:02 PM
| > To:	John Nels Fuller; P1394@Sun.COM; 1394ohci-l@austin.ibm.com
| > Subject:	Re[2]: "Loose Asynchronous" vs "Loose Isochronous"
| > 
| >      John,
| >      
| >      Thanks for the response.  Do you (or does someone) have a
| > reference in 
| >      a particular specification?  The L10:L0 transition in 6.3.3 of
| > the 
| >      1995 spec does not allow the isochronous period to end with
| > reception 
| >      of an asynchronous packet as you suggest, so I'm still hunting.
| > Any 
| >      help appreciated.
| >      
| >      Jerry
| > 
| > 
| > ______________________________ Reply Separator
| > _________________________________
| > Subject: RE: "Loose Asynchronous" vs "Loose Isochronous"
| > Author:  jfuller@MICROSOFT.com at SMTPGATE
| > Date:    5/30/97 5:15 PM
| > 
| > 
| > Jerry,
| >      
| > The spec is not silent on this subject.  I believe it says that if an 
| > async packet is seen during the iso period then the iso period ends
| > and 
| > the async packet is received normally.
| >      
| > I don't know if this is the desired behavior.  It is an interesting
| > idea 
| > to schedule "async" packets during iso in order to have a private iso 
| > stream.  However, in order to avoid having to put on flame retardant,
| > I 
| > will quickly say that I'm not proposing we make a change but I'm just 
| > trying to say that if you don't like what is currently spec'd there
| > are 
| > a lot more possibilities than the two you list.
| >      
| > _____________________
| > John Nels Fuller
| > Software Design Engineer, Windows NT 
| > Microsoft Corporation
| > One Microsoft Way
| > Redmond, WA   98052-6399
| > Voice: (425) 703-3863
| > Fax: (425) 93 MSFAX
| >      
| >      
| > > -----Original Message-----
| > > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
| > > Sent:     Friday, May 30, 1997 1:59 PM
| > > To:     P1394@Sun.COM; 1394ohci-l@austin.ibm.com
| > > Subject:     "Loose Asynchronous" vs "Loose Isochronous" 
| > >
| > >      I believe discussions regarding "asynchronous streams" and lost
| > 
| > > cycle
| > >      start packets have led both OHCI and P1394a to a "loose 
| > > isochronous"
| > >      interpretation which allows the link to receive isochronous 
| > > packets
| > >      within the asynchronous period.  (In fact, OHCI mandates "loose
| > 
| > >      isochronous" implementations.)
| > >
| > >      But what behavior should be specified if an otherwise valid
| > >      asynchronous packet is received during the isochronous period 
| > > (i.e.,
| > >      between cycle start and the first subaction gap)?  Assuming the
| > 
| > > specs
| > >      are currently silent on the point, I think there are two basic 
| > >      options:
| > >
| > >      1) Continue to say nothing in the specifications ... the 
| > > reception of
| > >      an asynchronous packet during the isochronous period is clearly
| > 
| > > the
| > >      sign of a broken bus.  Don't force implementations to check or 
| > >      correct.
| > >
| > >      2) Require that links NOT issue an acknowledge packet.
| > (Issuing 
| > > an
| > >      acknowledge would likely interfere with isochronous
| > arbitration.) 
| > > In
| > >      the case of OHCI, the link could pass the packet up the stack 
| > > with an
| > >      event code of ack_missing.
| > >
| > >      Does anyone feel that the packet (assuming it passes CRC) must
| > be 
| > >
| > >      accepted by the link and processed as if received during the
| > >      asynchronous period (with the exception of the ack generation).
| > 
| > >
| > >      Feedback requested,
| > >      Jerry Hauck
| > >      Intel Corp.
| > >      jerry_hauck@ccm.sc.intel.com
| 
From:	Eric W. Anderson [ewa@apple.com]
Sent:	Monday, June 02, 1997 11:47 AM
To:	DavidW@bangate.compaq.com; P1394@sun.com; 1394ohci-l@austin.ibm.com
Subject:	re: RE: Re[2]: "Loose Asynchronous" vs "Loose Isochronous"

I agree with David - we should state that we do not ack such packets.

But, I want us to also clearly state WHY this is specified.  Even though
the reason may seem blindingly obvious to us at this moment, someone may
someday misinterpret us as trying to support asynch packets during the
isoch period.  I propose:

"OpenHCI will not send any acknowledgement to any packet received during
an isochronous period [meaning, each period starting when a cycle start
is sent or received and ending when a subaction gap first occurs].  This
behavior is specified only to limit the damage that would be caused by
the erroneous occurrance of an asynchronous packet during the isochronous
period, not to support or encourage the use of asynchronous packets during
the isochronous period."

"Note that such an erroneous asynchronous packet does not cause the
premature end of the isochronous period, as seen by OpenHCI."

"Note that a cycle synch event may occur while an asynchronous packet is
being received.  Such a packet can be acknowledged (if needed) prior to
the sending or receiving of the cycle start packet.  The above rule does
not apply, because the isochronous period does not begin until after the
acknowledgement (if any) is sent."

Whether to suppress iso transmission in such an event is an interesting
question.  If the rogue async packet causes cycleTooLong to happen, this
could wreak havoc on all isochronous activity.  If we suppressed our own
TX for one cycle instead, and avoided cycleTooLong, then at least some
isoch channels might survive unscathed.  Perhaps we could just chalk up
a cycle loss at that point, then we don't have to flush any packets.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------

On Mon, Jun 2, 1997 7:31 AM, David Wooten wrote:
>I think that Jerry's proposal that the link not send an ACK if an asynch 
>packet is received in the iso interval is the only one that keeps us out
of 
>trouble.  Depending on the speed of the asynch packet, some device may not
see 
>the asynch packet or the ACK so not all devices would end the iso
interval.  
>They will stay in iso mode and continue with normal iso arbitration.  So,
I 
>think that a device that tries to ACK an asynch packet during the iso
interval 
>will screw up the iso arbitration and things could really get screwed up
if we 
>don't require that the ACK be suppressed because an ACK can lead to
triggering 
> a node trying to do ack accelerated or flyby arbitration.  Now, it may be

>that we want a node to suppress any iso transmit when it sees an asynch
packet 
>go by (not a proposal) but it does not mean that the iso interval ends. 
Iso 
>interval still lasts until the subaction gap is seen.
>
>If we are going to add ack accelerations, we should also make a statement 
>about not acking during the iso interval and that an asynch packet does
not 
>end the iso interval so no ack accelerations are triggered even if an ack
is 
>seen during the iso interval. (I wanted to make that a longer, run on
sentence 
>but I couldn't think of anything more to add.)
>
>David Wooten
>
>
>John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
>| 
>| Jerry,
>| 
>| I can't remember who told me that this was the behavior, but it seems to
>| disagree with the behavior described in the description of the L13:L10
>| transition.
>| 
>| > -----Original Message-----
>| > From:	Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com]
>| > Sent:	Friday, May 30, 1997 6:02 PM
>| > To:	John Nels Fuller; P1394@Sun.COM; 1394ohci-l@austin.ibm.com
>| > Subject:	Re[2]: "Loose Asynchronous" vs "Loose Isochronous"
>| > 
>| >      John,
>| >      
>| >      Thanks for the response.  Do you (or does someone) have a
>| > reference in 
>| >      a particular specification?  The L10:L0 transition in 6.3.3 of
>| > the 
>| >      1995 spec does not allow the isochronous period to end with
>| > reception 
>| >      of an asynchronous packet as you suggest, so I'm still hunting.
>| > Any 
>| >      help appreciated.
>| >      
>| >      Jerry
>| > 
>| > 
>| > ______________________________ Reply Separator
>| > _________________________________
>| > Subject: RE: "Loose Asynchronous" vs "Loose Isochronous"
>| > Author:  jfuller@MICROSOFT.com at SMTPGATE
>| > Date:    5/30/97 5:15 PM
>| > 
>| > 
>| > Jerry,
>| >      
>| > The spec is not silent on this subject.  I believe it says that if an 
>| > async packet is seen during the iso period then the iso period ends
>| > and 
>| > the async packet is received normally.
>| >      
>| > I don't know if this is the desired behavior.  It is an interesting
>| > idea 
>| > to schedule "async" packets during iso in order to have a private iso 
>| > stream.  However, in order to avoid having to put on flame retardant,
>| > I 
>| > will quickly say that I'm not proposing we make a change but I'm just 
>| > trying to say that if you don't like what is currently spec'd there
>| > are 
>| > a lot more possibilities than the two you list.
>| >      
>| > _____________________
>| > John Nels Fuller
>| > Software Design Engineer, Windows NT 
>| > Microsoft Corporation
>| > One Microsoft Way
>| > Redmond, WA   98052-6399
>| > Voice: (425) 703-3863
>| > Fax: (425) 93 MSFAX
>| >      
>| >      
>| > > -----Original Message-----
>| > > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
>| > > Sent:     Friday, May 30, 1997 1:59 PM
>| > > To:     P1394@Sun.COM; 1394ohci-l@austin.ibm.com
>| > > Subject:     "Loose Asynchronous" vs "Loose Isochronous" 
>| > >
>| > >      I believe discussions regarding "asynchronous streams" and lost
>| > 
>| > > cycle
>| > >      start packets have led both OHCI and P1394a to a "loose 
>| > > isochronous"
>| > >      interpretation which allows the link to receive isochronous 
>| > > packets
>| > >      within the asynchronous period.  (In fact, OHCI mandates "loose
>| > 
>| > >      isochronous" implementations.)
>| > >
>| > >      But what behavior should be specified if an otherwise valid
>| > >      asynchronous packet is received during the isochronous period 
>| > > (i.e.,
>| > >      between cycle start and the first subaction gap)?  Assuming the
>| > 
>| > > specs
>| > >      are currently silent on the point, I think there are two basic 
>| > >      options:
>| > >
>| > >      1) Continue to say nothing in the specifications ... the 
>| > > reception of
>| > >      an asynchronous packet during the isochronous period is clearly
>| > 
>| > > the
>| > >      sign of a broken bus.  Don't force implementations to check or 
>| > >      correct.
>| > >
>| > >      2) Require that links NOT issue an acknowledge packet.
>| > (Issuing 
>| > > an
>| > >      acknowledge would likely interfere with isochronous
>| > arbitration.) 
>| > > In
>| > >      the case of OHCI, the link could pass the packet up the stack 
>| > > with an
>| > >      event code of ack_missing.
>| > >
>| > >      Does anyone feel that the packet (assuming it passes CRC) must
>| > be 
>| > >
>| > >      accepted by the link and processed as if received during the
>| > >      asynchronous period (with the exception of the ack generation).
>| > 
>| > >
>| > >      Feedback requested,
>| > >      Jerry Hauck
>| > >      Intel Corp.
>| > >      jerry_hauck@ccm.sc.intel.com



From:	Lee Wilson [leew@austin.ibm.com]
Sent:	Monday, June 02, 1997 10:31 AM
To:	1394ohci-l
Subject:	Log of All Reflector Traffic

Greetings,

    I have put a new version of the reflector log on the 

ftp://www.austin.ibm.com/pub/chrptech/1394ohci/

ftp site.  The file names are OHCI_May.pst (exchange 
file) and OHCI_May.txt.  For those of you who are new to 
the reflector, the foils from the conferences and the specs
(all PDFs) are kept there too.

   Best Regards,
   Lee
From:	Colin Whitby-Strevens [colinws@bristol.st.com]
Sent:	Tuesday, June 03, 1997 10:00 AM
To:	ewa@apple.com; DavidW@bangate.compaq.com; P1394@sun.com; 1394ohci-l@austin.ibm.com
Subject:	Re: re: RE: Re[2]: "Loose Asynchronous" vs "Loose Isochronous"

>I agree with David - we should state that we do not ack such packets.
>
>But, I want us to also clearly state WHY this is specified.  Even though
>the reason may seem blindingly obvious to us at this moment, someone may
>someday misinterpret us as trying to support asynch packets during the
>isoch period.  I propose:
>
>"OpenHCI will not send any acknowledgement to any packet received during
>an isochronous period [meaning, each period starting when a cycle start
>is sent or received and ending when a subaction gap first occurs].  This
>behavior is specified only to limit the damage that would be caused by
>the erroneous occurrance of an asynchronous packet during the isochronous
>period, not to support or encourage the use of asynchronous packets
> during
>the isochronous period."

We noted in the last P1394a meeting that it is possible for one node to 
detect the sub-action gap which terminates the isoch cycle, and transmit an 
asynch packet, before the PHY on some other node sees the sub-action gap.

Thus this second node link layer will see the asynch packet apparently 
during the isoch cycle.

We proposed wording to the effect that the isoch cycle is terminated either 
by the subaction gap or by reception of an asynchronous packet.

With best wishes

Colin W-S


>
>"Note that such an erroneous asynchronous packet does not cause the
>premature end of the isochronous period, as seen by OpenHCI."
>
>"Note that a cycle synch event may occur while an asynchronous packet is
>being received.  Such a packet can be acknowledged (if needed) prior to
>the sending or receiving of the cycle start packet.  The above rule does
>not apply, because the isochronous period does not begin until after the
>acknowledgement (if any) is sent."
>
>Whether to suppress iso transmission in such an event is an interesting
>question.  If the rogue async packet causes cycleTooLong to happen, this
>could wreak havoc on all isochronous activity.  If we suppressed our own
>TX for one cycle instead, and avoided cycleTooLong, then at least some
>isoch channels might survive unscathed.  Perhaps we could just chalk up
>a cycle loss at that point, then we don't have to flush any packets.
>
>--------------------------------------
>Eric Anderson            ewa@apple.com
>Apple Computer, Inc.     (408)974-8187
>--------------------------------------
>
>On Mon, Jun 2, 1997 7:31 AM, David Wooten wrote:
>>I think that Jerry's proposal that the link not send an ACK if an asynch
>>packet is received in the iso interval is the only one that keeps us
> out
>of 
>>trouble.  Depending on the speed of the asynch packet, some device may
> not
>see 
>>the asynch packet or the ACK so not all devices would end the iso
>interval.  
>>They will stay in iso mode and continue with normal iso arbitration. 
> So,
>I 
>>think that a device that tries to ACK an asynch packet during the iso
>interval 
>>will screw up the iso arbitration and things could really get screwed
> up
>if we 
>>don't require that the ACK be suppressed because an ACK can lead to
>triggering 
>> a node trying to do ack accelerated or flyby arbitration.  Now, it may
> be
>
>>that we want a node to suppress any iso transmit when it sees an asynch
>packet 
>>go by (not a proposal) but it does not mean that the iso interval ends.
>Iso 
>>interval still lasts until the subaction gap is seen.
>>
>>If we are going to add ack accelerations, we should also make a
> statement 
>>about not acking during the iso interval and that an asynch packet does
>not 
>>end the iso interval so no ack accelerations are triggered even if an
> ack
>is 
>>seen during the iso interval. (I wanted to make that a longer, run on
>sentence 
>>but I couldn't think of anything more to add.)
>>
>>David Wooten
>>
>>
>>John Nels Fuller <jfuller@MICROSOFT.com> Wrote:
>>| 
>>| Jerry,
>>| 
>>| I can't remember who told me that this was the behavior, but it seems
> to
>>| disagree with the behavior described in the description of the
> L13:L10
>>| transition.
>>| 
>>| > -----Original Message-----
>>| > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com]
>>| > Sent:     Friday, May 30, 1997 6:02 PM
>>| > To:       John Nels Fuller; P1394@Sun.COM; 1394ohci-l@austin.ibm.com
>>| > Subject:  Re[2]: "Loose Asynchronous" vs "Loose Isochronous"
>>| > 
>>| >      John,
>>| >      
>>| >      Thanks for the response.  Do you (or does someone) have a
>>| > reference in 
>>| >      a particular specification?  The L10:L0 transition in 6.3.3 of
>>| > the 
>>| >      1995 spec does not allow the isochronous period to end with
>>| > reception 
>>| >      of an asynchronous packet as you suggest, so I'm still
> hunting.
>>| > Any 
>>| >      help appreciated.
>>| >      
>>| >      Jerry
>>| > 
>>| > 
>>| > ______________________________ Reply Separator
>>| > _________________________________
>>| > Subject: RE: "Loose Asynchronous" vs "Loose Isochronous"
>>| > Author:  jfuller@MICROSOFT.com at SMTPGATE
>>| > Date:    5/30/97 5:15 PM
>>| > 
>>| > 
>>| > Jerry,
>>| >      
>>| > The spec is not silent on this subject.  I believe it says that if
> an 
>>| > async packet is seen during the iso period then the iso period ends
>>| > and 
>>| > the async packet is received normally.
>>| >      
>>| > I don't know if this is the desired behavior.  It is an interesting
>>| > idea 
>>| > to schedule "async" packets during iso in order to have a private
> iso 
>>| > stream.  However, in order to avoid having to put on flame retardant,
>>| > I 
>>| > will quickly say that I'm not proposing we make a change but I'm
> just 
>>| > trying to say that if you don't like what is currently spec'd there
>>| > are 
>>| > a lot more possibilities than the two you list.
>>| >      
>>| > _____________________
>>| > John Nels Fuller
>>| > Software Design Engineer, Windows NT 
>>| > Microsoft Corporation
>>| > One Microsoft Way
>>| > Redmond, WA   98052-6399
>>| > Voice: (425) 703-3863
>>| > Fax: (425) 93 MSFAX
>>| >      
>>| >      
>>| > > -----Original Message-----
>>| > > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
>>| > > Sent:     Friday, May 30, 1997 1:59 PM
>>| > > To:     P1394@Sun.COM; 1394ohci-l@austin.ibm.com
>>| > > Subject:     "Loose Asynchronous" vs "Loose Isochronous" 
>>| > >
>>| > >      I believe discussions regarding "asynchronous streams" and
> lost
>>| > 
>>| > > cycle
>>| > >      start packets have led both OHCI and P1394a to a "loose 
>>| > > isochronous"
>>| > >      interpretation which allows the link to receive isochronous 
>>| > > packets
>>| > >      within the asynchronous period.  (In fact, OHCI mandates
> "loose
>>| > 
>>| > >      isochronous" implementations.)
>>| > >
>>| > >      But what behavior should be specified if an otherwise valid
>>| > >      asynchronous packet is received during the isochronous period
>>| > > (i.e.,
>>| > >      between cycle start and the first subaction gap)?  Assuming
> the
>>| > 
>>| > > specs
>>| > >      are currently silent on the point, I think there are two
> basic 
>>| > >      options:
>>| > >
>>| > >      1) Continue to say nothing in the specifications ... the 
>>| > > reception of
>>| > >      an asynchronous packet during the isochronous period is
> clearly
>>| > 
>>| > > the
>>| > >      sign of a broken bus.  Don't force implementations to check
> or 
>>| > >      correct.
>>| > >
>>| > >      2) Require that links NOT issue an acknowledge packet.
>>| > (Issuing 
>>| > > an
>>| > >      acknowledge would likely interfere with isochronous
>>| > arbitration.) 
>>| > > In
>>| > >      the case of OHCI, the link could pass the packet up the stack
>>| > > with an
>>| > >      event code of ack_missing.
>>| > >
>>| > >      Does anyone feel that the packet (assuming it passes CRC)
> must
>>| > be 
>>| > >
>>| > >      accepted by the link and processed as if received during the
>>| > >      asynchronous period (with the exception of the ack generation)
>.
>>| > 
>>| > >
>>| > >      Feedback requested,
>>| > >      Jerry Hauck
>>| > >      Intel Corp.
>>| > >      jerry_hauck@ccm.sc.intel.com
>
>
>
>
>

--
Colin Whitby-Strevens             email:colinws@bristol.st.com
SGS-THOMSON Microelectronic       tel: +44 1454 611500
1000, Aztec West                  fax: +44 1454 617910
Almondsbury
BRISTOL BS12 4SQ 
UK
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Tuesday, June 03, 1997 10:42 AM
To:	colinws@bristol.st.com; P1394@sun.com; 1394ohci-l@austin.ibm.com
Subject:	Re[6]: "Loose Asynchronous" vs "Loose Isochronou


Text item: 

     Colin,
     
     Please remind me of the case in which one node detects a sub-action 
     and another doesn't.
     
     By my recollection, this situation can only occur if a PHY is unable 
     to send the subaction gap status indication because it is busy doing a 
     register transfer.  After some debate, I thought this situation was 
     cleanly resolved by requiring that PHY's NOT initiate the register 
     status transfer in the vicinity of a subaction gap.
     
     What did I miss?
     
     Thanks kindly,
     
     Jerry Hauck
     Intel Corp
     jerry_hauck@ccm.sc.intel.com
     (408) 765-5528


______________________________ Reply Separator _________________________________
Subject: Re: re: RE: Re[2]: "Loose Asynchronous" vs "Loose Isochronou
Author:  colinws@bristol.st.com at SMTPGATE
Date:    6/3/97 6:00 PM


>I agree with David - we should state that we do not ack such packets. 
>
>But, I want us to also clearly state WHY this is specified.  Even though 
>the reason may seem blindingly obvious to us at this moment, someone may 
>someday misinterpret us as trying to support asynch packets during the 
>isoch period.  I propose:
>
>"OpenHCI will not send any acknowledgement to any packet received during 
>an isochronous period [meaning, each period starting when a cycle start 
>is sent or received and ending when a subaction gap first occurs].  This 
>behavior is specified only to limit the damage that would be caused by 
>the erroneous occurrance of an asynchronous packet during the isochronous 
>period, not to support or encourage the use of asynchronous packets
> during
>the isochronous period."
     
We noted in the last P1394a meeting that it is possible for one node to 
detect the sub-action gap which terminates the isoch cycle, and transmit an 
asynch packet, before the PHY on some other node sees the sub-action gap.
     
Thus this second node link layer will see the asynch packet apparently 
during the isoch cycle.
     
We proposed wording to the effect that the isoch cycle is terminated either 
by the subaction gap or by reception of an asynchronous packet.
     
With best wishes
     
Colin W-S
     
     
>
>"Note that such an erroneous asynchronous packet does not cause the 
>premature end of the isochronous period, as seen by OpenHCI."
>
>"Note that a cycle synch event may occur while an asynchronous packet is 
>being received.  Such a packet can be acknowledged (if needed) prior to 
>the sending or receiving of the cycle start packet.  The above rule does 
>not apply, because the isochronous period does not begin until after the 
>acknowledgement (if any) is sent."
>
>Whether to suppress iso transmission in such an event is an interesting 
>question.  If the rogue async packet causes cycleTooLong to happen, this 
>could wreak havoc on all isochronous activity.  If we suppressed our own 
>TX for one cycle instead, and avoided cycleTooLong, then at least some 
>isoch channels might survive unscathed.  Perhaps we could just chalk up 
>a cycle loss at that point, then we don't have to flush any packets.
>
>-------------------------------------- 
>Eric Anderson            ewa@apple.com 
>Apple Computer, Inc.     (408)974-8187 
>-------------------------------------- 
>
>On Mon, Jun 2, 1997 7:31 AM, David Wooten wrote:
>>I think that Jerry's proposal that the link not send an ACK if an asynch 
>>packet is received in the iso interval is the only one that keeps us
> out
>of
>>trouble.  Depending on the speed of the asynch packet, some device may 
> not
>see
>>the asynch packet or the ACK so not all devices would end the iso 
>interval.
>>They will stay in iso mode and continue with normal iso arbitration. 
> So,
>I
>>think that a device that tries to ACK an asynch packet during the iso 
>interval
>>will screw up the iso arbitration and things could really get screwed 
> up
>if we
>>don't require that the ACK be suppressed because an ACK can lead to 
>triggering
>> a node trying to do ack accelerated or flyby arbitration.  Now, it may 
> be
>
>>that we want a node to suppress any iso transmit when it sees an asynch 
>packet
>>go by (not a proposal) but it does not mean that the iso interval ends. 
>Iso
>>interval still lasts until the subaction gap is seen. 
>>
>>If we are going to add ack accelerations, we should also make a 
> statement
>>about not acking during the iso interval and that an asynch packet does 
>not
>>end the iso interval so no ack accelerations are triggered even if an 
> ack
>is
>>seen during the iso interval. (I wanted to make that a longer, run on 
>sentence
>>but I couldn't think of anything more to add.) 
>>
>>David Wooten
>>
>>
>>John Nels Fuller <jfuller@MICROSOFT.com> Wrote: 
>>|
>>| Jerry,
>>|
>>| I can't remember who told me that this was the behavior, but it seems 
> to
>>| disagree with the behavior described in the description of the 
> L13:L10
>>| transition.
>>|
>>| > -----Original Message-----
>>| > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
>>| > Sent:     Friday, May 30, 1997 6:02 PM
>>| > To:       John Nels Fuller; P1394@Sun.COM; 1394ohci-l@austin.ibm.com 
>>| > Subject:  Re[2]: "Loose Asynchronous" vs "Loose Isochronous"
>>| >
>>| >      John,
>>| >
>>| >      Thanks for the response.  Do you (or does someone) have a 
>>| > reference in
>>| >      a particular specification?  The L10:L0 transition in 6.3.3 of 
>>| > the
>>| >      1995 spec does not allow the isochronous period to end with 
>>| > reception
>>| >      of an asynchronous packet as you suggest, so I'm still 
> hunting.
>>| > Any
>>| >      help appreciated.
>>| >
>>| >      Jerry
>>| >
>>| >
>>| > ______________________________ Reply Separator 
>>| > _________________________________
>>| > Subject: RE: "Loose Asynchronous" vs "Loose Isochronous" 
>>| > Author:  jfuller@MICROSOFT.com at SMTPGATE
>>| > Date:    5/30/97 5:15 PM
>>| >
>>| >
>>| > Jerry,
>>| >
>>| > The spec is not silent on this subject.  I believe it says that if 
> an
>>| > async packet is seen during the iso period then the iso period ends 
>>| > and
>>| > the async packet is received normally. 
>>| >
>>| > I don't know if this is the desired behavior.  It is an interesting 
>>| > idea
>>| > to schedule "async" packets during iso in order to have a private 
> iso
>>| > stream.  However, in order to avoid having to put on flame retardant, 
>>| > I
>>| > will quickly say that I'm not proposing we make a change but I'm 
> just
>>| > trying to say that if you don't like what is currently spec'd there 
>>| > are
>>| > a lot more possibilities than the two you list. 
>>| >
>>| > _____________________
>>| > John Nels Fuller
>>| > Software Design Engineer, Windows NT 
>>| > Microsoft Corporation
>>| > One Microsoft Way
>>| > Redmond, WA   98052-6399
>>| > Voice: (425) 703-3863
>>| > Fax: (425) 93 MSFAX
>>| >
>>| >
>>| > > -----Original Message-----
>>| > > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
>>| > > Sent:     Friday, May 30, 1997 1:59 PM
>>| > > To:     P1394@Sun.COM; 1394ohci-l@austin.ibm.com
>>| > > Subject:     "Loose Asynchronous" vs "Loose Isochronous" 
>>| > >
>>| > >      I believe discussions regarding "asynchronous streams" and 
> lost
>>| >
>>| > > cycle
>>| > >      start packets have led both OHCI and P1394a to a "loose 
>>| > > isochronous"
>>| > >      interpretation which allows the link to receive isochronous 
>>| > > packets
>>| > >      within the asynchronous period.  (In fact, OHCI mandates 
> "loose
>>| >
>>| > >      isochronous" implementations.) 
>>| > >
>>| > >      But what behavior should be specified if an otherwise valid 
>>| > >      asynchronous packet is received during the isochronous period 
>>| > > (i.e.,
>>| > >      between cycle start and the first subaction gap)?  Assuming 
> the
>>| >
>>| > > specs
>>| > >      are currently silent on the point, I think there are two 
> basic
>>| > >      options:
>>| > >
>>| > >      1) Continue to say nothing in the specifications ... the 
>>| > > reception of
>>| > >      an asynchronous packet during the isochronous period is 
> clearly
>>| >
>>| > > the
>>| > >      sign of a broken bus.  Don't force implementations to check 
> or
>>| > >      correct.
>>| > >
>>| > >      2) Require that links NOT issue an acknowledge packet. 
>>| > (Issuing
>>| > > an
>>| > >      acknowledge would likely interfere with isochronous 
>>| > arbitration.)
>>| > > In
>>| > >      the case of OHCI, the link could pass the packet up the stack 
>>| > > with an
>>| > >      event code of ack_missing. 
>>| > >
>>| > >      Does anyone feel that the packet (assuming it passes CRC) 
> must
>>| > be
>>| > >
>>| > >      accepted by the link and processed as if received during the 
>>| > >      asynchronous period (with the exception of the ack generation) 
>.
>>| >
>>| > >
>>| > >      Feedback requested,
>>| > >      Jerry Hauck
>>| > >      Intel Corp.
>>| > >      jerry_hauck@ccm.sc.intel.com 
>
>
>
>
>
     
--
Colin Whitby-Strevens             email:colinws@bristol.st.com 
SGS-THOMSON Microelectronic       tel: +44 1454 611500
1000, Aztec West                  fax: +44 1454 617910 
Almondsbury
BRISTOL BS12 4SQ
UK

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Transfer-Encoding: 7bit
Content-Type: text/plain
MIME-Version: 1.0
X-Mailer: Pronto Mobile [wrq Ver 2.1]
Subject: Re: re: RE: Re[2]: "Loose Asynchronous" vs "Loose Isochronous"
X-Priority: Normal
To: ewa@apple.com, DavidW@bangate.compaq.com, P1394@Sun.COM,
        1394ohci-l@austin.ibm.com
From: Colin Whitby-Strevens <colinws@bristol.st.com>
Message-Id: <199706031700.SAA19302@buttercup.inmos.co.uk>
Date: Tue, 3 Jun 1997 18:00:02 +0100 (BST)
Received: by buttercup.inmos.co.uk id SAA19302; Tue, 3 Jun 1997 18:00:02 +0100 (
BST)
Received: by hawkweed id SAA20799; Tue, 3 Jun 1997 18:00:07 +0100 (BST)
Received: from hawkweed (hawkweed.bri.st.com [192.26.234.4]) by saturn.Sun.COM (
SMI-8.6/mail.byaddr) with SMTP id KAA13727 for <P1394@Sun.COM>; Tue, 3 Jun 1997
10:00:53 -0700
Received: from saturn.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1)
     id JAA18464; Tue, 3 Jun 1997 09:59:29 -0700
Received: from sunmail1.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3)
     id JAA23373; Tue, 3 Jun 1997 09:59:35 -0700
Received: from Eng.Sun.COM by scsi.eng.sun.com (SMI-8.6/SMI-SVR4)
     id KAA03629; Tue, 3 Jun 1997 10:02:37 -0700
Received: from scsi.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
     id KAA11606; Tue, 3 Jun 1997 10:00:06 -0700
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.bya
ddr) with SMTP id KAA20245; Tue, 3 Jun 1997 10:19:08 -0700
Received: from mercury.Sun.COM by imssc2.sc.intel.com (8.8.4/10.0i); Tue, 3 Jun
1997 17:28:44 GMT
Received: from imssc2.sc.intel.com (imssc2.sc.intel.com [143.183.152.8]) by prai
rie.sc.intel.com (8.7.3/8.7.3) with ESMTP id JAA20545 for <Jerry_Hauck@ccm.sc.in
tel.com>; Tue, 3 Jun 1997 09:28:25 -0700 (PDT)
Return-Path: colinws@bristol.st.com
From:	Vilas Bhade [vilas@wipro.com]
Sent:	Tuesday, June 03, 1997 12:07 PM
To:	colinws@bristol.st.com; P1394@Sun.COM; 1394ohci-l@austin.ibm.com; 'Jerry Hauck'
Subject:	RE: Re[6]: "Loose Asynchronous" vs "Loose Isochronou

Jerry

I guess the wording of Colin mail require change to address this border case , which 
got resolve at Phoenix (MAY) meeting.

Is it OK ?

Vilas
Wipro Ltd
Cupertino CA USA
Tel 408-777-4723.

----------
From:  Jerry Hauck[SMTP:Jerry_Hauck@ccm.sc.intel.com]
Sent:  Tuesday, June 03, 1997 10:42 AM
To:  colinws@bristol.st.com; P1394@Sun.COM; 1394ohci-l@austin.ibm.com
Subject:  Re[6]: "Loose Asynchronous" vs "Loose Isochronou


Text item: 

     Colin,
     
     Please remind me of the case in which one node detects a sub-action 
     and another doesn't.
     
     By my recollection, this situation can only occur if a PHY is unable 
     to send the subaction gap status indication because it is busy doing a 
     register transfer.  After some debate, I thought this situation was 
     cleanly resolved by requiring that PHY's NOT initiate the register 
     status transfer in the vicinity of a subaction gap.
     
     What did I miss?
     
     Thanks kindly,
     
     Jerry Hauck
     Intel Corp
     jerry_hauck@ccm.sc.intel.com
     (408) 765-5528


______________________________ Reply Separator _________________________________
Subject: Re: re: RE: Re[2]: "Loose Asynchronous" vs "Loose Isochronou
Author:  colinws@bristol.st.com at SMTPGATE
Date:    6/3/97 6:00 PM


>I agree with David - we should state that we do not ack such packets. 
>
>But, I want us to also clearly state WHY this is specified.  Even though 
>the reason may seem blindingly obvious to us at this moment, someone may 
>someday misinterpret us as trying to support asynch packets during the 
>isoch period.  I propose:
>
>"OpenHCI will not send any acknowledgement to any packet received during 
>an isochronous period [meaning, each period starting when a cycle start 
>is sent or received and ending when a subaction gap first occurs].  This 
>behavior is specified only to limit the damage that would be caused by 
>the erroneous occurrance of an asynchronous packet during the isochronous 
>period, not to support or encourage the use of asynchronous packets
> during
>the isochronous period."
     
We noted in the last P1394a meeting that it is possible for one node to 
detect the sub-action gap which terminates the isoch cycle, and transmit an 
asynch packet, before the PHY on some other node sees the sub-action gap.
     
Thus this second node link layer will see the asynch packet apparently 
during the isoch cycle.
     
We proposed wording to the effect that the isoch cycle is terminated either 
by the subaction gap or by reception of an asynchronous packet.
     
With best wishes
     
Colin W-S
     
     
>
>"Note that such an erroneous asynchronous packet does not cause the 
>premature end of the isochronous period, as seen by OpenHCI."
>
>"Note that a cycle synch event may occur while an asynchronous packet is 
>being received.  Such a packet can be acknowledged (if needed) prior to 
>the sending or receiving of the cycle start packet.  The above rule does 
>not apply, because the isochronous period does not begin until after the 
>acknowledgement (if any) is sent."
>
>Whether to suppress iso transmission in such an event is an interesting 
>question.  If the rogue async packet causes cycleTooLong to happen, this 
>could wreak havoc on all isochronous activity.  If we suppressed our own 
>TX for one cycle instead, and avoided cycleTooLong, then at least some 
>isoch channels might survive unscathed.  Perhaps we could just chalk up 
>a cycle loss at that point, then we don't have to flush any packets.
>
>-------------------------------------- 
>Eric Anderson            ewa@apple.com 
>Apple Computer, Inc.     (408)974-8187 
>-------------------------------------- 
>
>On Mon, Jun 2, 1997 7:31 AM, David Wooten wrote:
>>I think that Jerry's proposal that the link not send an ACK if an asynch 
>>packet is received in the iso interval is the only one that keeps us
> out
>of
>>trouble.  Depending on the speed of the asynch packet, some device may 
> not
>see
>>the asynch packet or the ACK so not all devices would end the iso 
>interval.
>>They will stay in iso mode and continue with normal iso arbitration. 
> So,
>I
>>think that a device that tries to ACK an asynch packet during the iso 
>interval
>>will screw up the iso arbitration and things could really get screwed 
> up
>if we
>>don't require that the ACK be suppressed because an ACK can lead to 
>triggering
>> a node trying to do ack accelerated or flyby arbitration.  Now, it may 
> be
>
>>that we want a node to suppress any iso transmit when it sees an asynch 
>packet
>>go by (not a proposal) but it does not mean that the iso interval ends. 
>Iso
>>interval still lasts until the subaction gap is seen. 
>>
>>If we are going to add ack accelerations, we should also make a 
> statement
>>about not acking during the iso interval and that an asynch packet does 
>not
>>end the iso interval so no ack accelerations are triggered even if an 
> ack
>is
>>seen during the iso interval. (I wanted to make that a longer, run on 
>sentence
>>but I couldn't think of anything more to add.) 
>>
>>David Wooten
>>
>>
>>John Nels Fuller <jfuller@MICROSOFT.com> Wrote: 
>>|
>>| Jerry,
>>|
>>| I can't remember who told me that this was the behavior, but it seems 
> to
>>| disagree with the behavior described in the description of the 
> L13:L10
>>| transition.
>>|
>>| > -----Original Message-----
>>| > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
>>| > Sent:     Friday, May 30, 1997 6:02 PM
>>| > To:       John Nels Fuller; P1394@Sun.COM; 1394ohci-l@austin.ibm.com 
>>| > Subject:  Re[2]: "Loose Asynchronous" vs "Loose Isochronous"
>>| >
>>| >      John,
>>| >
>>| >      Thanks for the response.  Do you (or does someone) have a 
>>| > reference in
>>| >      a particular specification?  The L10:L0 transition in 6.3.3 of 
>>| > the
>>| >      1995 spec does not allow the isochronous period to end with 
>>| > reception
>>| >      of an asynchronous packet as you suggest, so I'm still 
> hunting.
>>| > Any
>>| >      help appreciated.
>>| >
>>| >      Jerry
>>| >
>>| >
>>| > ______________________________ Reply Separator 
>>| > _________________________________
>>| > Subject: RE: "Loose Asynchronous" vs "Loose Isochronous" 
>>| > Author:  jfuller@MICROSOFT.com at SMTPGATE
>>| > Date:    5/30/97 5:15 PM
>>| >
>>| >
>>| > Jerry,
>>| >
>>| > The spec is not silent on this subject.  I believe it says that if 
> an
>>| > async packet is seen during the iso period then the iso period ends 
>>| > and
>>| > the async packet is received normally. 
>>| >
>>| > I don't know if this is the desired behavior.  It is an interesting 
>>| > idea
>>| > to schedule "async" packets during iso in order to have a private 
> iso
>>| > stream.  However, in order to avoid having to put on flame retardant, 
>>| > I
>>| > will quickly say that I'm not proposing we make a change but I'm 
> just
>>| > trying to say that if you don't like what is currently spec'd there 
>>| > are
>>| > a lot more possibilities than the two you list. 
>>| >
>>| > _____________________
>>| > John Nels Fuller
>>| > Software Design Engineer, Windows NT 
>>| > Microsoft Corporation
>>| > One Microsoft Way
>>| > Redmond, WA   98052-6399
>>| > Voice: (425) 703-3863
>>| > Fax: (425) 93 MSFAX
>>| >
>>| >
>>| > > -----Original Message-----
>>| > > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
>>| > > Sent:     Friday, May 30, 1997 1:59 PM
>>| > > To:     P1394@Sun.COM; 1394ohci-l@austin.ibm.com
>>| > > Subject:     "Loose Asynchronous" vs "Loose Isochronous" 
>>| > >
>>| > >      I believe discussions regarding "asynchronous streams" and 
> lost
>>| >
>>| > > cycle
>>| > >      start packets have led both OHCI and P1394a to a "loose 
>>| > > isochronous"
>>| > >      interpretation which allows the link to receive isochronous 
>>| > > packets
>>| > >      within the asynchronous period.  (In fact, OHCI mandates 
> "loose
>>| >
>>| > >      isochronous" implementations.) 
>>| > >
>>| > >      But what behavior should be specified if an otherwise valid 
>>| > >      asynchronous packet is received during the isochronous period 
>>| > > (i.e.,
>>| > >      between cycle start and the first subaction gap)?  Assuming 
> the
>>| >
>>| > > specs
>>| > >      are currently silent on the point, I think there are two 
> basic
>>| > >      options:
>>| > >
>>| > >      1) Continue to say nothing in the specifications ... the 
>>| > > reception of
>>| > >      an asynchronous packet during the isochronous period is 
> clearly
>>| >
>>| > > the
>>| > >      sign of a broken bus.  Don't force implementations to check 
> or
>>| > >      correct.
>>| > >
>>| > >      2) Require that links NOT issue an acknowledge packet. 
>>| > (Issuing
>>| > > an
>>| > >      acknowledge would likely interfere with isochronous 
>>| > arbitration.)
>>| > > In
>>| > >      the case of OHCI, the link could pass the packet up the stack 
>>| > > with an
>>| > >      event code of ack_missing. 
>>| > >
>>| > >      Does anyone feel that the packet (assuming it passes CRC) 
> must
>>| > be
>>| > >
>>| > >      accepted by the link and processed as if received during the 
>>| > >      asynchronous period (with the exception of the ack generation) 
>.
>>| >
>>| > >
>>| > >      Feedback requested,
>>| > >      Jerry Hauck
>>| > >      Intel Corp.
>>| > >      jerry_hauck@ccm.sc.intel.com 
>
>
>
>
>
     
--
Colin Whitby-Strevens             email:colinws@bristol.st.com 
SGS-THOMSON Microelectronic       tel: +44 1454 611500
1000, Aztec West                  fax: +44 1454 617910 
Almondsbury
BRISTOL BS12 4SQ
UK

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Transfer-Encoding: 7bit
Content-Type: text/plain
MIME-Version: 1.0
X-Mailer: Pronto Mobile [wrq Ver 2.1]
Subject: Re: re: RE: Re[2]: "Loose Asynchronous" vs "Loose Isochronous"
X-Priority: Normal
To: ewa@apple.com, DavidW@bangate.compaq.com, P1394@Sun.COM,
        1394ohci-l@austin.ibm.com
From: Colin Whitby-Strevens <colinws@bristol.st.com>
Message-Id: <199706031700.SAA19302@buttercup.inmos.co.uk>
Date: Tue, 3 Jun 1997 18:00:02 +0100 (BST)
Received: by buttercup.inmos.co.uk id SAA19302; Tue, 3 Jun 1997 18:00:02 +0100 (
BST)
Received: by hawkweed id SAA20799; Tue, 3 Jun 1997 18:00:07 +0100 (BST)
Received: from hawkweed (hawkweed.bri.st.com [192.26.234.4]) by saturn.Sun.COM (
SMI-8.6/mail.byaddr) with SMTP id KAA13727 for <P1394@Sun.COM>; Tue, 3 Jun 1997
10:00:53 -0700
Received: from saturn.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1)
     id JAA18464; Tue, 3 Jun 1997 09:59:29 -0700
Received: from sunmail1.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3)
     id JAA23373; Tue, 3 Jun 1997 09:59:35 -0700
Received: from Eng.Sun.COM by scsi.eng.sun.com (SMI-8.6/SMI-SVR4)
     id KAA03629; Tue, 3 Jun 1997 10:02:37 -0700
Received: from scsi.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
     id KAA11606; Tue, 3 Jun 1997 10:00:06 -0700
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.bya
ddr) with SMTP id KAA20245; Tue, 3 Jun 1997 10:19:08 -0700
Received: from mercury.Sun.COM by imssc2.sc.intel.com (8.8.4/10.0i); Tue, 3 Jun
1997 17:28:44 GMT
Received: from imssc2.sc.intel.com (imssc2.sc.intel.com [143.183.152.8]) by prai
rie.sc.intel.com (8.7.3/8.7.3) with ESMTP id JAA20545 for <Jerry_Hauck@ccm.sc.in
tel.com>; Tue, 3 Jun 1997 09:28:25 -0700 (PDT)
Return-Path: colinws@bristol.st.com

From:	PJohansson@aol.com
Sent:	Tuesday, June 03, 1997 2:27 PM
To:	P1394@sun.com
Cc:	1394ohci-l@austin.ibm.com
Subject:	Re: "Loose Asynchronous" vs "Loose Isochronous"

I support Jerry's second proposal that:

 a) packets received during the isochronous period that have non-isochronous
tcodes do NOT receive an ACK; and

 b) the isochronous period ends with the observance of a subaction gap, not
by the errant, asynchronous packet.

Regards,

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson@aol.com
From:	Sunny Lam [sunnyl@us.ibm.com]
Sent:	Tuesday, June 03, 1997 5:15 PM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe to 1394ohci reflector

subscribe to 1394ohci reflector
From:	Todd Roper [troper@3a.com]
Sent:	Wednesday, June 04, 1997 7:35 AM
To:	'1394ohci-l@austin.ibm.com'
Subject:	unsubscribe

unsubscribe troper@3a.com
From:	Patrick_Yu@el.nec.com
Sent:	Wednesday, June 04, 1997 2:01 PM
To:	p1394b@fireflyinc.com; P1394@sun.com; P1394.bridges@sun.com; 1394ohci-l@austin.ibm.com
Subject:	1.04 revision of Device Power Management spec

     
The latest version of 1394 Power Management proposal.  Thanks.

Yours sincerely,
W.S.P. Yu

______________________________ Forward Header __________________________________
Subject: 1.04 revision of Device Power Management spec
Author:  Mike Flora <mikefl@MICROSOFT.com> at INTERNET
Date:    6/4/97 12:50 PM


Here it is, only a few days late.  Would someone please forward to the 
1394TA and 1394a reflectors?
     
     
     
Please review this and send comments on the reflector; Please DON'T wait 
until the 6/12-13 meeting to raise issues, as we need to _finalize_ this 
at that meeting.
     
Thanks,
     
Mike
     

The following is an attached File item from cc:Mail.  It contains
information that had to be encoded to ensure successful transmission
through various mail systems.  To decode the file use the UUDECODE
program.
--------------------------------- Cut Here ---------------------------------
From:	Mark Hardgrave [Mark_Hardgrave@maxtor.com]
Sent:	Wednesday, June 04, 1997 4:08 PM
To:	1394ohci-l@austin.ibm.com
Subject:	ohci reflector

To whom it may concern:

	I would like to receive information on the OHCI host interface for 
1394.
	My name is Mark Hardgrave, I work for MAXTOR (a member of the 1394 
TA), and I have signed up as a member of the TA myself.
	
Thanks
MTH
From:	John Nels Fuller
Sent:	Thursday, June 05, 1997 12:25 AM
To:	1394-power; Mike Flora
Cc:	Clark Sealls; Shaun Pierce; Rob McKaughan; P1394; P1394b; P1394.bridges; 1394OpenHCI
Subject:	RE: 1.04 revision of Device Power Management spec

A quick review of this document found two (typographical) errors, which
may be my fault since they both come from private comments I gave to
Mike:

1) There is a typo in section 5.1.3:  "RES_CONFLICT_ERROR" should be
"RESP_CONFLICT_ERROR."

2) The inserted text right after the title "5.3.1 UNIT_POWER_STATE
register" should be in the following section titled "5.3.2
UNIT_POWER_CONTROL register" and there is a typo in this paragraph:
"thisd" should be "this."

> ----------
> From: 	Mike Flora
> Sent: 	Wednesday, June 04, 1997 12:42 PM
> To: 	'list@p1394pm.org'
> Cc: 	Clark Sealls; Shaun Pierce; Rob McKaughan
> Subject: 	1.04 revision of Device Power Management spec
> 
> <<File: pmgtv104.zip>>
> Here it is, only a few days late.  Would someone please forward to the
> 1394TA and 1394a reflectors?
> 
>  
> 
> Please review this and send comments on the reflector; Please DON'T
> wait
> until the 6/12-13 meeting to raise issues, as we need to _finalize_
> this
> at that meeting.
> 
> Thanks,
> 
> Mike
> 
From:	Mike Flora
Sent:	Thursday, June 05, 1997 9:20 AM
To:	John Nels Fuller; '1394-power'
Cc:	Clark Sealls; Shaun Pierce; Rob McKaughan; 'P1394'; 'P1394b'; 'P1394.bridges'; '1394OpenHCI'
Subject:	RE: 1.04 revision of Device Power Management spec

Thanks, John,  These are my mistakes.  I'll fix them for the meeting.

Mike

		-----Original Message-----
		From:	John Nels Fuller 
		Sent:	Thursday, June 05, 1997 12:25 AM
		To:	1394-power; Mike Flora
		Cc:	Clark Sealls; Shaun Pierce; Rob McKaughan;
P1394; P1394b; P1394.bridges; 1394OpenHCI
		Subject:	RE: 1.04 revision of Device Power
Management spec

		A quick review of this document found two
(typographical) errors, which may be my fault since they both come from
private comments I gave to Mike:

		1) There is a typo in section 5.1.3:
"RES_CONFLICT_ERROR" should be "RESP_CONFLICT_ERROR."

		2) The inserted text right after the title "5.3.1
UNIT_POWER_STATE register" should be in the following section titled
"5.3.2 UNIT_POWER_CONTROL register" and there is a typo in this
paragraph: "thisd" should be "this."

			----------
			From: 	Mike Flora
			Sent: 	Wednesday, June 04, 1997 12:42 PM
			To: 	'list@p1394pm.org'
			Cc: 	Clark Sealls; Shaun Pierce; Rob
McKaughan
			Subject: 	1.04 revision of Device Power
Management spec

			<<File: pmgtv104.zip>>
			Here it is, only a few days late.  Would someone
please forward to the
			1394TA and 1394a reflectors?

			 

			Please review this and send comments on the
reflector; Please DON'T wait
			until the 6/12-13 meeting to raise issues, as we
need to _finalize_ this
			at that meeting.

			Thanks,

			Mike
From:	Rob Lash [rlash@qntm.com]
Sent:	Thursday, June 05, 1997 10:56 AM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

subscribe

----------------------------------------------------------------- 
  Rob Lash
  Sr. Firmware Engineer                  email: rlash@qntm.com
  Advanced Development                   voice: 408.894.4228
  Quantum Corporation                    fax:   408.894.5653
  500 McCarthy Blvd                     
  Milpitas, CA 95035                     http://www.quantum.com
-----------------------------------------------------------------
From:	Kent Pryor [kpryor@qntm.com]
Sent:	Thursday, June 05, 1997 11:03 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Subscribption request, Kent Pryor, Quantum Corp.

subscribe kpryor@qntm.com
From:	Kalaine M. Wong [Kalaine.Wong@clssnis0.amd.com]
Sent:	Thursday, June 05, 1997 6:18 PM
To:	1394ohci-l@austin.ibm.com; p1394@sun.com
Subject:	LINK asserts IDLE

Hi:

	In section 5.1.3 of the 1394a v0.08, the last paragraph states that the
LINK "releases the bus by asserting IDLE on the Ctl signals for TWO SClk
cycles."  However, in Figure 5-4, it shows that the LINK only asserts
IDLE (00) for one clock before releasing it to ZZ.

	Which one is correct?

Thanks,
Kalaine
 
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{									 }
{			    Have a nice day :-)				 }
{									 }
{	Kalaine Mak Wong			kalaine.wong@amd.com	 }
{	Advanced Micro Devices			TEL: (408) 749-4919 or	 }
{	Platform Peripheral Division		(800) 538-8450 X44919	 }
{	Senior Design Engineer			FAX: (408) 749-4753 	 }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	Colin Whitby-Strevens [colinws@bristol.st.com]
Sent:	Friday, June 06, 1997 6:57 AM
To:	Kalaine.Wong@clssnis0.amd.com; 1394ohci-l@austin.ibm.com; p1394@sun.com
Subject:	Re: LINK asserts IDLE

Hello

Just a tangential comment - the PHY-LINK handover protocol has been changed 
several times in recent iterations (I think only affecting the PHY to LINK 
handover though, your comment affects LINK to PHY handover). There is also 
a general action arising from the last P1394a meeting for PHY and LINK 
designers to review how the recently agreed PHY-LINK AC timings might 
affect this.

We have made such a review, and wish to propose that it is altered again 
(back to one of the previous versions)!!!!

So I think that this should be on the agenda for the next P1394a meeting.
Equally, if you can also make a review from your point of view, then this 
would be helpful.

Note that the revised PHY-LINK electrical spec (which now includes a DC 
spec) was recently circulated on this reflector, and (IMHO) supersedes 
Draft D0.08.

With best wishes

Colin Whitby-Strevens

>Hi:
>
>       In section 5.1.3 of the 1394a v0.08, the last paragraph states that 
the
>LINK "releases the bus by asserting IDLE on the Ctl signals for TWO SClk
>cycles."  However, in Figure 5-4, it shows that the LINK only asserts
>IDLE (00) for one clock before releasing it to ZZ.
>
>       Which one is correct?
>
>Thanks,
>Kalaine
> 
>-- 
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>{                                                                       }
>{                          Have a nice day :-)                          }
>{                                                                       }
>{      Kalaine Mak Wong                        kalaine.wong@amd.com     }
>{      Advanced Micro Devices                  TEL: (408) 749-4919 or   }
>{      Platform Peripheral Division            (800) 538-8450 X44919    }
>{      Senior Design Engineer                  FAX: (408) 749-4753      }
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

--
Colin Whitby-Strevens             email:colinws@bristol.st.com
SGS-THOMSON Microelectronic       tel: +44 1454 611500
1000, Aztec West                  fax: +44 1454 617910
Almondsbury
BRISTOL BS12 4SQ 
UK
From:	Mark Knecht [markk@phoenix.com]
Sent:	Friday, June 06, 1997 7:30 AM
To:	1394ohci-l@austin.ibm.com; p1394@Sun.COM
Cc:	'Kalaine.Wong@clssnis0.amd.com'
Subject:	RE: LINK asserts IDLE

Kalaine,
   It looks to me as if you caught a small inconsistency in the specifications. Checking 1394-1995 it was there also.

   I believe that the text is correct and that two clock cycles is called for. Looking at the upper part of Fig. 5-4 it shows two cycles. I bet that in the lower part of 5-4 (J-4 in 1394-1995) the third cycle, shown as a hold (01), should have been an idle, (00) in which case the diagram would have been correct. I expect that this is the mistake because the numbering of the data shows the last packet (Dn) transferred on clock 2, thus eliminating the need to insert a hold.

   Could the Phy design community reply as to what they are expecting?

Thanks,

Mark Knecht
Chief Architect, Virtual Chips Products
Phoenix Technologies, Ltd.


----------
From: 	Kalaine M. Wong
Sent: 	Thursday, June 05, 1997 6:18 PM
To: 	1394ohci-l@austin.ibm.com; p1394@Sun.COM
Subject: 	LINK asserts IDLE

Hi:

	In section 5.1.3 of the 1394a v0.08, the last paragraph states that the
LINK "releases the bus by asserting IDLE on the Ctl signals for TWO SClk
cycles."  However, in Figure 5-4, it shows that the LINK only asserts
IDLE (00) for one clock before releasing it to ZZ.

	Which one is correct?

Thanks,
Kalaine
 
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{									 }
{			    Have a nice day :-)				 }
{									 }
{	Kalaine Mak Wong			kalaine.wong@amd.com	 }
{	Advanced Micro Devices			TEL: (408) 749-4919 or	 }
{	Platform Peripheral Division		(800) 538-8450 X44919	 }
{	Senior Design Engineer			FAX: (408) 749-4753 	 }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From:	Jim Skidmore [j-skidmore@ti.com]
Sent:	Friday, June 06, 1997 10:45 AM
To:	1394ohci-l@austin.ibm.com; Mark Knecht; p1394@Sun.COM
Cc:	'Kalaine.Wong@clssnis0.amd.com'
Subject:	RE: LINK asserts IDLE

All,
Both the text and the figures are correct.  The last paragraph of 5.1.3 is
refering to the LAST packet of a string of concatenated packets or a single
packet.  Refer to the 2nd paragragh of 5.1.3, which describes how to indicate
that a concatenated packet is to be sent.

- To indicate that the serial-bus is to be held for a subsequent concatenated
packet, the link terminates packet transmission by asserting HOLD, then IDLE on
the link interface.

- To indicate that the serial-bus may be released, the link terminates packet
transmission by asserting IDLE for 2 cycles on the link interface.


>  From: Mark Knecht <markk@phoenix.com>, on 6/6/97 7:29 AM:
>  Kalaine,
>     It looks to me as if you caught a small inconsistency in the 
>  specifications. Checking 1394-1995 it was there also.
>  
>     I believe that the text is correct and that two clock cycles is called 
>  for. Looking at the upper part of Fig. 5-4 it shows two cycles. I bet that 
>  in the lower part of 5-4 (J-4 in 1394-1995) the third cycle, shown as a hold 
>  (01), should have been an idle, (00) in which case the diagram would have 
>  been correct. I expect that this is the mistake because the numbering of the 
>  data shows the last packet (Dn) transferred on clock 2, thus eliminating the 
>  need to insert a hold.
>  
>     Could the Phy design community reply as to what they are expecting?
>  
>  Thanks,
>  
>  Mark Knecht
>  Chief Architect, Virtual Chips Products
>  Phoenix Technologies, Ltd.
>  
>  
>  ----------
>  From:   Kalaine M. Wong
>  Sent:   Thursday, June 05, 1997 6:18 PM
>  To:     1394ohci-l@austin.ibm.com; p1394@Sun.COM
>  Subject:        LINK asserts IDLE
>  
>  Hi:
>  
>          In section 5.1.3 of the 1394a v0.08, the last paragraph states that 
>  the
>  LINK "releases the bus by asserting IDLE on the Ctl signals for TWO SClk
>  cycles."  However, in Figure 5-4, it shows that the LINK only asserts
>  IDLE (00) for one clock before releasing it to ZZ.
>  
>          Which one is correct?
>  
>  Thanks,
>  Kalaine
>   
>  -- 
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  {                                                                        }
>  {                           Have a nice day :-)                          }
>  {                                                                        }
>  {       Kalaine Mak Wong                        kalaine.wong@amd.com     }
>  {       Advanced Micro Devices                  TEL: (408) 749-4919 or   }
>  {       Platform Peripheral Division            (800) 538-8450 X44919    }
>  {       Senior Design Engineer                  FAX: (408) 749-4753      }
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
>  

Regards,
Jim Skidmore

Texas Instruments Incorporated	| E-mail: j-skidmore@ti.com
Advanced Serial Bus Design	| MSG-ID: JSKD PC-DROP : PFLL
P.O. Box 660199, MS-8701	| Phone: 972/480-2094
Dallas, TX 75266-0199		| Fax: 972/480-2270
From:	heilmann@VNET.IBM.COM
Sent:	Friday, June 06, 1997 11:20 AM
To:	1394ohci-l@austin.ibm.com; p1394@sun.com
Subject:	Link asserts Idle.

We agree with Jim Skidmore that both the spec and the draft are
correct.  The link inserts idle for 2 cycles after transmitting
the LAST packet.  The link assets hold for 1 clock cycle and idle for
one clock cycle between concatenated packets.  In both cases, there
are two cycles used to turn the link/phy interface back over to the
PHY (HOLD-IDLE or IDLE-IDLE).

Regards,
Keith & Lou


ATTACHING PREVIOUS NOTES:

 =========================================================================
 Received: from mercury.Sun.COM by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP;
    Fri, 06 Jun 97 11:50:25 EDT
 Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM
 (SMI-8.6/mail.byaddr) with SMTP id JAA11167; Fri, 6 Jun 1997 09:06:55 -0700
 Received: from scsi.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
 	id IAA18554; Fri, 6 Jun 1997 08:47:04 -0700
 Received: from Eng.Sun.COM by scsi.eng.sun.com (SMI-8.6/SMI-SVR4)
 	id IAA07800; Fri, 6 Jun 1997 08:49:32 -0700
 Received: from sunmail1.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3)
 	id IAA19849; Fri, 6 Jun 1997 08:46:27 -0700
 Received: from venus.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1)
 	id IAA07919; Fri, 6 Jun 1997 08:46:23 -0700
 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by venus.Sun.COM
 (SMI-8.6/mail.byaddr) with ESMTP id IAA23353 for <p1394@Sun.COM>; Fri, 6 Jun
 1997 08:47:16 -0700
 Received: from dflp1.itg.ti.com ([156.117.175.5]) by dragon.ti.com (8.8.5)
 with ESMTP id KAA11077; Fri, 6 Jun 1997 10:47:12 -0500 (CDT)
 Received: from ti (CNA0153587.sc.ti.com [172.24.180.108])
 	by dflp1.itg.ti.com (8.8.5/8.8.5) with SMTP id KAA17650;
 	Fri, 6 Jun 1997 10:47:10 -0500 (CDT)
 X-Mailer: BeyondMail for Windows/Professional 2.3
 MIME-Version: 1.0
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7Bit
 To: "1394ohci-l@austin.ibm.com" <1394ohci-l@austin.ibm.com>,
         Mark Knecht
 	<markk@phoenix.com>, "p1394@Sun.COM" <p1394@Sun.COM>
 From: Jim Skidmore <j-skidmore@ti.com>
 Subject: RE: LINK asserts IDLE
 Date: Fri, 6 Jun 1997 10:45:25 -0700
 X-BeyondMail-Priority: 1
 Message-Id: <BMSMTP8656185264a0153587@dflmail.itg.ti.com>
 Conversation-Id: <01BC724B.6A5FACE0@markk.phoenix.com>
 In-Reply-To: <01BC724B.6A5FACE0@markk.phoenix.com>
 Reply-To: Jim Skidmore <j-skidmore@ti.com>
 Cc: "'Kalaine.Wong@clssnis0.amd.com'" <Kalaine.Wong@clssnis0.amd.com>
 X-Receipt-From-Agent: true

 All,
 Both the text and the figures are correct.  The last paragraph of 5.1.3 is
 refering to the LAST packet of a string of concatenated packets or a single
 packet.  Refer to the 2nd paragragh of 5.1.3, which describes how to indicate
 that a concatenated packet is to be sent.

 - To indicate that the serial-bus is to be held for a subsequent concatenated
 packet, the link terminates packet transmission by asserting HOLD, then IDLE on
 the link interface.

 - To indicate that the serial-bus may be released, the link terminates packet
 transmission by asserting IDLE for 2 cycles on the link interface.


 >  From: Mark Knecht <markk@phoenix.com>, on 6/6/97 7:29 AM:
 >  Kalaine,
 >     It looks to me as if you caught a small inconsistency in the
 >  specifications. Checking 1394-1995 it was there also.
 >
 >     I believe that the text is correct and that two clock cycles is called
 >  for. Looking at the upper part of Fig. 5-4 it shows two cycles. I bet that
 >  in the lower part of 5-4 (J-4 in 1394-1995) the third cycle, shown as a
 hold
 >  (01), should have been an idle, (00) in which case the diagram would have
 >  been correct. I expect that this is the mistake because the numbering of
 the
 >  data shows the last packet (Dn) transferred on clock 2, thus eliminating
 the
 >  need to insert a hold.
 >
 >     Could the Phy design community reply as to what they are expecting?
 >
 >  Thanks,
 >
 >  Mark Knecht
 >  Chief Architect, Virtual Chips Products
 >  Phoenix Technologies, Ltd.
 >
 >
 >  ----------
 >  From:   Kalaine M. Wong
 >  Sent:   Thursday, June 05, 1997 6:18 PM
 >  To:     1394ohci-l@austin.ibm.com; p1394@Sun.COM
 >  Subject:        LINK asserts IDLE
 >
 >  Hi:
 >
 >          In section 5.1.3 of the 1394a v0.08, the last paragraph states that
 >  the
 >  LINK "releases the bus by asserting IDLE on the Ctl signals for TWO SClk
 >  cycles."  However, in Figure 5-4, it shows that the LINK only asserts
 >  IDLE (00) for one clock before releasing it to ZZ.
 >
 >          Which one is correct?
 >
 >  Thanks,
 >  Kalaine
 >
 >  --
 >  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 >  {                                                                        }
 >  {                           Have a nice day :-)                          }
 >  {                                                                        }
 >  {       Kalaine Mak Wong                        kalaine.wong@amd.com     }
 >  {       Advanced Micro Devices                  TEL: (408) 749-4919 or   }
 >  {       Platform Peripheral Division            (800) 538-8450 X44919    }
 >  {       Senior Design Engineer                  FAX: (408) 749-4753      }
 >  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 >
 >

 Regards,
 Jim Skidmore

 Texas Instruments Incorporated	| E-mail: j-skidmore@ti.com
 Advanced Serial Bus Design	| MSG-ID: JSKD PC-DROP : PFLL
 P.O. Box 660199, MS-8701	| Phone: 972/480-2094
 Dallas, TX 75266-0199		| Fax: 972/480-2270
From:	Tommy Morris [tmorris@ti.com]
Sent:	Friday, June 06, 1997 11:39 AM
To:	1394ohci-l@austin.ibm.com; p1394@sun.com
Subject:	Re: Link asserts Idle.

unsubscribe tmorris@ti.com


>X-Sender: toni@bugs.skipstone.com
>Date: Fri, 06 Jun 1997 13:27:28 -0500
>To: Tommy Morris <tmorris@ti.com>
>From: Toni Tappan <toni@skipstone.com>
>Subject: Re: Link asserts Idle.
>
>Hi Tommy,
>Sorry but  I can't.this is not a TA reflector. You will just need to write
>to them and say "unsubscribe"
>toni
>
>At 01:22 PM 6/6/97 -0500, you wrote:
>>Toni, can you help me get removed from this reflector?
>>
>>Thanks,
>>Tommy
>>
>>>From: heilmann@VNET.IBM.COM
>>>Date: Fri, 6 Jun 97 14:20:01 EDT
>>>To: 1394ohci-l@austin.ibm.com, p1394@Sun.COM
>>>Subject: Link asserts Idle.
>>>
>>>We agree with Jim Skidmore that both the spec and the draft are
>>>correct.  The link inserts idle for 2 cycles after transmitting
>>>the LAST packet.  The link assets hold for 1 clock cycle and idle for
>>>one clock cycle between concatenated packets.  In both cases, there
>>>are two cycles used to turn the link/phy interface back over to the
>>>PHY (HOLD-IDLE or IDLE-IDLE).
>>>
>>>Regards,
>>>Keith & Lou
>>>
>>>
>>>ATTACHING PREVIOUS NOTES:
>>>
>>> =========================================================================
>>> Received: from mercury.Sun.COM by vnet.IBM.COM (IBM VM SMTP V2R3) with
TCP;
>>>    Fri, 06 Jun 97 11:50:25 EDT
>>> Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM
>>> (SMI-8.6/mail.byaddr) with SMTP id JAA11167; Fri, 6 Jun 1997 09:06:55
-0700
>>> Received: from scsi.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
>>> 	id IAA18554; Fri, 6 Jun 1997 08:47:04 -0700
>>> Received: from Eng.Sun.COM by scsi.eng.sun.com (SMI-8.6/SMI-SVR4)
>>> 	id IAA07800; Fri, 6 Jun 1997 08:49:32 -0700
>>> Received: from sunmail1.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3)
>>> 	id IAA19849; Fri, 6 Jun 1997 08:46:27 -0700
>>> Received: from venus.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1)
>>> 	id IAA07919; Fri, 6 Jun 1997 08:46:23 -0700
>>> Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by
>venus.Sun.COM
>>> (SMI-8.6/mail.byaddr) with ESMTP id IAA23353 for <p1394@Sun.COM>; Fri, 6
>Jun
>>> 1997 08:47:16 -0700
>>> Received: from dflp1.itg.ti.com ([156.117.175.5]) by dragon.ti.com (8.8.5)
>>> with ESMTP id KAA11077; Fri, 6 Jun 1997 10:47:12 -0500 (CDT)
>>> Received: from ti (CNA0153587.sc.ti.com [172.24.180.108])
>>> 	by dflp1.itg.ti.com (8.8.5/8.8.5) with SMTP id KAA17650;
>>> 	Fri, 6 Jun 1997 10:47:10 -0500 (CDT)
>>> X-Mailer: BeyondMail for Windows/Professional 2.3
>>> MIME-Version: 1.0
>>> Content-Type: text/plain; charset=us-ascii
>>> Content-Transfer-Encoding: 7Bit
>>> To: "1394ohci-l@austin.ibm.com" <1394ohci-l@austin.ibm.com>,
>>>         Mark Knecht
>>> 	<markk@phoenix.com>, "p1394@Sun.COM" <p1394@Sun.COM>
>>> From: Jim Skidmore <j-skidmore@ti.com>
>>> Subject: RE: LINK asserts IDLE
>>> Date: Fri, 6 Jun 1997 10:45:25 -0700
>>> X-BeyondMail-Priority: 1
>>> Message-Id: <BMSMTP8656185264a0153587@dflmail.itg.ti.com>
>>> Conversation-Id: <01BC724B.6A5FACE0@markk.phoenix.com>
>>> In-Reply-To: <01BC724B.6A5FACE0@markk.phoenix.com>
>>> Reply-To: Jim Skidmore <j-skidmore@ti.com>
>>> Cc: "'Kalaine.Wong@clssnis0.amd.com'" <Kalaine.Wong@clssnis0.amd.com>
>>> X-Receipt-From-Agent: true
>>>
>>> All,
>>> Both the text and the figures are correct.  The last paragraph of 5.1.3 is
>>> refering to the LAST packet of a string of concatenated packets or a
single
>>> packet.  Refer to the 2nd paragragh of 5.1.3, which describes how to
>>indicate
>>> that a concatenated packet is to be sent.
>>>
>>> - To indicate that the serial-bus is to be held for a subsequent
>>concatenated
>>> packet, the link terminates packet transmission by asserting HOLD, then
>>IDLE on
>>> the link interface.
>>>
>>> - To indicate that the serial-bus may be released, the link terminates
>>packet
>>> transmission by asserting IDLE for 2 cycles on the link interface.
>>>
>>>
>>> >  From: Mark Knecht <markk@phoenix.com>, on 6/6/97 7:29 AM:
>>> >  Kalaine,
>>> >     It looks to me as if you caught a small inconsistency in the
>>> >  specifications. Checking 1394-1995 it was there also.
>>> >
>>> >     I believe that the text is correct and that two clock cycles is
>called
>>> >  for. Looking at the upper part of Fig. 5-4 it shows two cycles. I bet
>>that
>>> >  in the lower part of 5-4 (J-4 in 1394-1995) the third cycle, shown as a
>>> hold
>>> >  (01), should have been an idle, (00) in which case the diagram would
>have
>>> >  been correct. I expect that this is the mistake because the
numbering of
>>> the
>>> >  data shows the last packet (Dn) transferred on clock 2, thus
eliminating
>>> the
>>> >  need to insert a hold.
>>> >
>>> >     Could the Phy design community reply as to what they are expecting?
>>> >
>>> >  Thanks,
>>> >
>>> >  Mark Knecht
>>> >  Chief Architect, Virtual Chips Products
>>> >  Phoenix Technologies, Ltd.
>>> >
>>> >
>>> >  ----------
>>> >  From:   Kalaine M. Wong
>>> >  Sent:   Thursday, June 05, 1997 6:18 PM
>>> >  To:     1394ohci-l@austin.ibm.com; p1394@Sun.COM
>>> >  Subject:        LINK asserts IDLE
>>> >
>>> >  Hi:
>>> >
>>> >          In section 5.1.3 of the 1394a v0.08, the last paragraph states
>>that
>>> >  the
>>> >  LINK "releases the bus by asserting IDLE on the Ctl signals for TWO
SClk
>>> >  cycles."  However, in Figure 5-4, it shows that the LINK only asserts
>>> >  IDLE (00) for one clock before releasing it to ZZ.
>>> >
>>> >          Which one is correct?
>>> >
>>> >  Thanks,
>>> >  Kalaine
>>> >
>>> >  --
>>> >
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >  {
>>  }
>>> >  {                           Have a nice day :-)
>>  }
>>> >  {
>>  }
>>> >  {       Kalaine Mak Wong                        kalaine.wong@amd.com
>>  }
>>> >  {       Advanced Micro Devices                  TEL: (408) 749-4919 or
>>  }
>>> >  {       Platform Peripheral Division            (800) 538-8450 X44919
>>  }
>>> >  {       Senior Design Engineer                  FAX: (408) 749-4753
>>  }
>>> >
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >
>>> >
>>>
>>> Regards,
>>> Jim Skidmore
>>>
>>> Texas Instruments Incorporated	| E-mail: j-skidmore@ti.com
>>> Advanced Serial Bus Design	| MSG-ID: JSKD PC-DROP : PFLL
>>> P.O. Box 660199, MS-8701	| Phone: 972/480-2094
>>> Dallas, TX 75266-0199		| Fax: 972/480-2270
>>>
>>>
>>
>>
>>+-------------------------------------------------------------------------+
>>|                                                     _/_/_/_/_/ _/_/_/   |
>>|Tommy Morris                     (972)480-4037          _/       _/      |
>>|Texas Instruments, Inc.          (972)480-4333  Fax    _/       _/       |
>>|ASIC Mass Storage Applications    tmorris@ti.com      _/       _/        |
>>|            	                                        _/     _/_/_/       |
>>+-------------------------------------------------------------------------+ 
>>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Toni Tappan
>1394 TA Administrator
>512-305-0203(1394 Trade Association)
>512-305-0212(Fax)
>toni@skipstone.com
>www.1394ta.org(TA Web Site)
>1394 Trade Association
>c/o Adaptec
>3925 W. Braker Ln., Ste. 425
>Austin, TX  78759
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>


+-------------------------------------------------------------------------+
|                                                     _/_/_/_/_/ _/_/_/   |
|Tommy Morris                     (972)480-4037          _/       _/      |
|Texas Instruments, Inc.          (972)480-4333  Fax    _/       _/       |
|ASIC Mass Storage Applications    tmorris@ti.com      _/       _/        |
|            	                                        _/     _/_/_/       |
+-------------------------------------------------------------------------+ 
From:	Jim_Busse@ccgate.sj.nec.com
Sent:	Friday, June 06, 1997 5:05 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Subscribe

     
Jim Busse
Chief Architect
NEC Systems Laboratory
339 N. Bernardo Ave.
Mountain View CA 94043

email:  jimb@ccgate.sj.nec.com

Telephone:  415-528-3810
Fax:  415-528-5900

From:	Mark Knecht [markk@phoenix.com]
Sent:	Friday, June 06, 1997 9:05 PM
To:	1394ohci-l@austin.ibm.com; p1394@sun.com
Subject:	RE: Link asserts Idle.

Keith, Lou & Jim,
   Thanks for the clarification. It was certainly unclear to me that I was looking at a queued second request there, but after your explanation the text was better understood. Thanks!
Regards,
Mark

----------
From: 	heilmann@VNET.IBM.COM
Sent: 	Friday, June 06, 1997 11:20 AM
To: 	1394ohci-l@austin.ibm.com; p1394@sun.com
Subject: 	Link asserts Idle.

We agree with Jim Skidmore that both the spec and the draft are
correct.  The link inserts idle for 2 cycles after transmitting
the LAST packet.  The link assets hold for 1 clock cycle and idle for
one clock cycle between concatenated packets.  In both cases, there
are two cycles used to turn the link/phy interface back over to the
PHY (HOLD-IDLE or IDLE-IDLE).

Regards,
Keith & Lou


ATTACHING PREVIOUS NOTES:

 =========================================================================
 Received: from mercury.Sun.COM by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP;
    Fri, 06 Jun 97 11:50:25 EDT
 Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM
 (SMI-8.6/mail.byaddr) with SMTP id JAA11167; Fri, 6 Jun 1997 09:06:55 -0700
 Received: from scsi.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
 	id IAA18554; Fri, 6 Jun 1997 08:47:04 -0700
 Received: from Eng.Sun.COM by scsi.eng.sun.com (SMI-8.6/SMI-SVR4)
 	id IAA07800; Fri, 6 Jun 1997 08:49:32 -0700
 Received: from sunmail1.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3)
 	id IAA19849; Fri, 6 Jun 1997 08:46:27 -0700
 Received: from venus.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1)
 	id IAA07919; Fri, 6 Jun 1997 08:46:23 -0700
 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by venus.Sun.COM
 (SMI-8.6/mail.byaddr) with ESMTP id IAA23353 for <p1394@Sun.COM>; Fri, 6 Jun
 1997 08:47:16 -0700
 Received: from dflp1.itg.ti.com ([156.117.175.5]) by dragon.ti.com (8.8.5)
 with ESMTP id KAA11077; Fri, 6 Jun 1997 10:47:12 -0500 (CDT)
 Received: from ti (CNA0153587.sc.ti.com [172.24.180.108])
 	by dflp1.itg.ti.com (8.8.5/8.8.5) with SMTP id KAA17650;
 	Fri, 6 Jun 1997 10:47:10 -0500 (CDT)
 X-Mailer: BeyondMail for Windows/Professional 2.3
 MIME-Version: 1.0
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7Bit
 To: "1394ohci-l@austin.ibm.com" <1394ohci-l@austin.ibm.com>,
         Mark Knecht
 	<markk@phoenix.com>, "p1394@Sun.COM" <p1394@Sun.COM>
 From: Jim Skidmore <j-skidmore@ti.com>
 Subject: RE: LINK asserts IDLE
 Date: Fri, 6 Jun 1997 10:45:25 -0700
 X-BeyondMail-Priority: 1
 Message-Id: <BMSMTP8656185264a0153587@dflmail.itg.ti.com>
 Conversation-Id: <01BC724B.6A5FACE0@markk.phoenix.com>
 In-Reply-To: <01BC724B.6A5FACE0@markk.phoenix.com>
 Reply-To: Jim Skidmore <j-skidmore@ti.com>
 Cc: "'Kalaine.Wong@clssnis0.amd.com'" <Kalaine.Wong@clssnis0.amd.com>
 X-Receipt-From-Agent: true

 All,
 Both the text and the figures are correct.  The last paragraph of 5.1.3 is
 refering to the LAST packet of a string of concatenated packets or a single
 packet.  Refer to the 2nd paragragh of 5.1.3, which describes how to indicate
 that a concatenated packet is to be sent.

 - To indicate that the serial-bus is to be held for a subsequent concatenated
 packet, the link terminates packet transmission by asserting HOLD, then IDLE on
 the link interface.

 - To indicate that the serial-bus may be released, the link terminates packet
 transmission by asserting IDLE for 2 cycles on the link interface.


 >  From: Mark Knecht <markk@phoenix.com>, on 6/6/97 7:29 AM:
 >  Kalaine,
 >     It looks to me as if you caught a small inconsistency in the
 >  specifications. Checking 1394-1995 it was there also.
 >
 >     I believe that the text is correct and that two clock cycles is called
 >  for. Looking at the upper part of Fig. 5-4 it shows two cycles. I bet that
 >  in the lower part of 5-4 (J-4 in 1394-1995) the third cycle, shown as a
 hold
 >  (01), should have been an idle, (00) in which case the diagram would have
 >  been correct. I expect that this is the mistake because the numbering of
 the
 >  data shows the last packet (Dn) transferred on clock 2, thus eliminating
 the
 >  need to insert a hold.
 >
 >     Could the Phy design community reply as to what they are expecting?
 >
 >  Thanks,
 >
 >  Mark Knecht
 >  Chief Architect, Virtual Chips Products
 >  Phoenix Technologies, Ltd.
 >
 >
 >  ----------
 >  From:   Kalaine M. Wong
 >  Sent:   Thursday, June 05, 1997 6:18 PM
 >  To:     1394ohci-l@austin.ibm.com; p1394@Sun.COM
 >  Subject:        LINK asserts IDLE
 >
 >  Hi:
 >
 >          In section 5.1.3 of the 1394a v0.08, the last paragraph states that
 >  the
 >  LINK "releases the bus by asserting IDLE on the Ctl signals for TWO SClk
 >  cycles."  However, in Figure 5-4, it shows that the LINK only asserts
 >  IDLE (00) for one clock before releasing it to ZZ.
 >
 >          Which one is correct?
 >
 >  Thanks,
 >  Kalaine
 >
 >  --
 >  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 >  {                                                                        }
 >  {                           Have a nice day :-)                          }
 >  {                                                                        }
 >  {       Kalaine Mak Wong                        kalaine.wong@amd.com     }
 >  {       Advanced Micro Devices                  TEL: (408) 749-4919 or   }
 >  {       Platform Peripheral Division            (800) 538-8450 X44919    }
 >  {       Senior Design Engineer                  FAX: (408) 749-4753      }
 >  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 >
 >

 Regards,
 Jim Skidmore

 Texas Instruments Incorporated	| E-mail: j-skidmore@ti.com
 Advanced Serial Bus Design	| MSG-ID: JSKD PC-DROP : PFLL
 P.O. Box 660199, MS-8701	| Phone: 972/480-2094
 Dallas, TX 75266-0199		| Fax: 972/480-2270



From:	okazaki@cpl.toshiba.co.jp
Sent:	Saturday, June 07, 1997 1:18 AM
To:	1394ohci-l@austin.ibm.com
Subject:	test please ignore

test

Jun Okazaki
 Toshiba Multimedia Engineering LAB.
E-mail: okazaki@cpl.toshiba.co.jp
Phone: +81-45-770-3314
Fax  : +81-45-770-3192
From:	amrits@eng.adaptec.com
Sent:	Monday, June 09, 1997 6:34 PM
To:	1394ohci-l@austin.ibm.com
Subject:	cycletimer update


********************************************************

Section 5.11 (Draft 0.93) states that "When the
1394 OpenHCI is not the cycle master, Isochronous 
Cycle Timer register is loaded with the data
field in an incoming cycle start."

This statement may need to be elaborated a bit, for
a couple of things that can cause confusion:
1. Last part should read "in each incoming cycle start".
2. As required in IEEE1394 spec. section 8.3.2.3.1
   titled CYCLE_TIME register, "A cycle slave shall
   implement a synchronization mechanism between the
   cycle start packets and the CYCLE_TIME register
   such that time, as observed by the values of the
   CYCLE_TIME register, never appears to move backwards."
   This will require that if OpenHCI cycle timer is 
   faster that the master's cycle timer, then OpenHCI 
   cycle timer must not load the received value right
   away. It may be implementation dependent how or
   when the OpenHCI cycle timer updates/resumes its count,
   but it is important to comply to the 1394 spec., lack
   of which may cause some target devices to be unhappy.

So there is some room for clarification.
If this has already been talked about and I have missed
the discussion (obviously), can someone please advise me?

Regards,
-amrit
************************************************************
Amrit Sra
Adaptec 
(408)-957-2202
amrits@eng.adaptec.com
From:	Colin Whitby-Strevens [colinws@bristol.st.com]
Sent:	Tuesday, June 10, 1997 5:41 AM
To:	Jerry_Hauck@ccm.sc.intel.com; P1394@sun.com; 1394ohci-l@austin.ibm.com
Subject:	Re: Re[6]: "Loose Asynchronous" vs "Loose Isochronou

You are right Jerry.

But the position is currently not sufficiently well defined for anyone to 
implement.

I quote below from the excellent P1394a minutes of the Phoenix meeting.

The conclusion IMHO is that the proposal for OHCI to ignore asynch packets 
received during an isochronous cycle (i.e. don't acknowledge them) is OK, 
on the assumption that P1394a is going to clean up the corner case as 
minuted.

With best wishes

Colin

===========================================================
Extract from P1394a minutes

PHY-Link interface corner case: Prashant Kanhere
================================================
Prashant presented a corner case in which a PHY may not be able to
send a subaction gap to the link. The scenario is as follows:
1.  The PHY has just entered the idle state and its arb counter is
counting up to the subaction gap.
2.  Just before the subaction gap is detected, the link completes a
register read request and the PHY starts a status transfer by
sending the first two status bits (arb reset gap and subaction
gap bits). Since the subaction gap has not been detected yet,
this bit will be zero.
3.  Subsequent to above, the PHY detects the subaction gap.
4.  The register request takes 8 SCLKs (160 ns). Before this is
complete, another node, having won the arbitration, starts
transmitting a packet. This PHY, upon sensing Data_Prefix,
terminates the status/register read transfer and asserts
RECEIVE on the control lines of the PHY link interface. At the
same time it also clears the subaction gap bit since this
condition is not valid any longer. Thus this subaction gap will
never be sent to the link.

Things get even more interesting if prior to the recognizing the
subaction gap the bus was in the isochronous phase. In this case,
the received packet will be an asynch packet. However, since the
link never received the subaction gap indication, it remains in
the isochronous state. Thus it will receive a asynch packet in
isochronous state. Further more, if the new asynch packet is aimed
at this node, the link will not be able to send an acknowledge
back since it is still in the asynch mode. After a lot of
discussion and several alternatives later, Neil Morrow suggested
that a 1394A PHY should defer servicing a read register request
from the link during a timing window (to be defined) before the
detection of the subaction gap. This will ensure that when the
read is actually serviced, the status bits will include the
subaction gap event indication as well. Prashant took the action
to send the definition of this new rule to the editor.
==========================================================


>
>Text item: 
>
>     Colin,
>     
>     Please remind me of the case in which one node detects a sub-action
>     and another doesn't.
>     
>     By my recollection, this situation can only occur if a PHY is unable
>     to send the subaction gap status indication because it is busy doing
> a 
>     register transfer.  After some debate, I thought this situation was
>     cleanly resolved by requiring that PHY's NOT initiate the register 
>     status transfer in the vicinity of a subaction gap.
>     
>     What did I miss?
>     
>     Thanks kindly,
>     
>     Jerry Hauck
>     Intel Corp
>     jerry_hauck@ccm.sc.intel.com
>     (408) 765-5528
>
>
>______________________________ Reply Separator ___________________________
>______
>Subject: Re: re: RE: Re[2]: "Loose Asynchronous" vs "Loose Isochronou
>Author:  colinws@bristol.st.com at SMTPGATE
>Date:    6/3/97 6:00 PM
>
>
>>I agree with David - we should state that we do not ack such packets. 
>>
>>But, I want us to also clearly state WHY this is specified.  Even though
>>the reason may seem blindingly obvious to us at this moment, someone may
>>someday misinterpret us as trying to support asynch packets during the 
>>isoch period.  I propose:
>>
>>"OpenHCI will not send any acknowledgement to any packet received during
>>an isochronous period [meaning, each period starting when a cycle start
>>is sent or received and ending when a subaction gap first occurs].  This
>>behavior is specified only to limit the damage that would be caused by 
>>the erroneous occurrance of an asynchronous packet during the isochronous
>>period, not to support or encourage the use of asynchronous packets
>> during
>>the isochronous period."
>     
>We noted in the last P1394a meeting that it is possible for one node to 
>detect the sub-action gap which terminates the isoch cycle, and transmit
> an 
>asynch packet, before the PHY on some other node sees the sub-action
> gap.
>     
>Thus this second node link layer will see the asynch packet apparently 
>during the isoch cycle.
>     
>We proposed wording to the effect that the isoch cycle is terminated
> either 
>by the subaction gap or by reception of an asynchronous packet.
>     
>With best wishes
>     
>Colin W-S
>     
>     
>>
>>"Note that such an erroneous asynchronous packet does not cause the 
>>premature end of the isochronous period, as seen by OpenHCI."
>>
>>"Note that a cycle synch event may occur while an asynchronous packet is
>>being received.  Such a packet can be acknowledged (if needed) prior to
>>the sending or receiving of the cycle start packet.  The above rule does
>>not apply, because the isochronous period does not begin until after the
>>acknowledgement (if any) is sent."
>>
>>Whether to suppress iso transmission in such an event is an interesting
>>question.  If the rogue async packet causes cycleTooLong to happen, this
>>could wreak havoc on all isochronous activity.  If we suppressed our own
>>TX for one cycle instead, and avoided cycleTooLong, then at least some 
>>isoch channels might survive unscathed.  Perhaps we could just chalk up
>>a cycle loss at that point, then we don't have to flush any packets.
>>
>>-------------------------------------- 
>>Eric Anderson            ewa@apple.com 
>>Apple Computer, Inc.     (408)974-8187 
>>-------------------------------------- 
>>
>>On Mon, Jun 2, 1997 7:31 AM, David Wooten wrote:
>>>I think that Jerry's proposal that the link not send an ACK if an
> asynch 
>>>packet is received in the iso interval is the only one that keeps us
>> out
>>of
>>>trouble.  Depending on the speed of the asynch packet, some device may
>> not
>>see
>>>the asynch packet or the ACK so not all devices would end the iso 
>>interval.
>>>They will stay in iso mode and continue with normal iso arbitration. 
>> So,
>>I
>>>think that a device that tries to ACK an asynch packet during the iso 
>>interval
>>>will screw up the iso arbitration and things could really get screwed 
>> up
>>if we
>>>don't require that the ACK be suppressed because an ACK can lead to 
>>triggering
>>> a node trying to do ack accelerated or flyby arbitration.  Now, it may
>> be
>>
>>>that we want a node to suppress any iso transmit when it sees an asynch
>>packet
>>>go by (not a proposal) but it does not mean that the iso interval ends.
>>Iso
>>>interval still lasts until the subaction gap is seen. 
>>>
>>>If we are going to add ack accelerations, we should also make a 
>> statement
>>>about not acking during the iso interval and that an asynch packet does
>>not
>>>end the iso interval so no ack accelerations are triggered even if an 
>> ack
>>is
>>>seen during the iso interval. (I wanted to make that a longer, run on 
>>sentence
>>>but I couldn't think of anything more to add.) 
>>>
>>>David Wooten
>>>
>>>
>>>John Nels Fuller <jfuller@MICROSOFT.com> Wrote: 
>>>|
>>>| Jerry,
>>>|
>>>| I can't remember who told me that this was the behavior, but it seems
>> to
>>>| disagree with the behavior described in the description of the 
>> L13:L10
>>>| transition.
>>>|
>>>| > -----Original Message-----
>>>| > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
>>>| > Sent:     Friday, May 30, 1997 6:02 PM
>>>| > To:       John Nels Fuller; P1394@Sun.COM; 1394ohci-l@austin.ibm.com
>>>| > Subject:  Re[2]: "Loose Asynchronous" vs "Loose Isochronous"
>>>| >
>>>| >      John,
>>>| >
>>>| >      Thanks for the response.  Do you (or does someone) have a 
>>>| > reference in
>>>| >      a particular specification?  The L10:L0 transition in 6.3.3 of
>>>| > the
>>>| >      1995 spec does not allow the isochronous period to end with 
>>>| > reception
>>>| >      of an asynchronous packet as you suggest, so I'm still 
>> hunting.
>>>| > Any
>>>| >      help appreciated.
>>>| >
>>>| >      Jerry
>>>| >
>>>| >
>>>| > ______________________________ Reply Separator 
>>>| > _________________________________
>>>| > Subject: RE: "Loose Asynchronous" vs "Loose Isochronous" 
>>>| > Author:  jfuller@MICROSOFT.com at SMTPGATE
>>>| > Date:    5/30/97 5:15 PM
>>>| >
>>>| >
>>>| > Jerry,
>>>| >
>>>| > The spec is not silent on this subject.  I believe it says that if
>> an
>>>| > async packet is seen during the iso period then the iso period ends
>>>| > and
>>>| > the async packet is received normally. 
>>>| >
>>>| > I don't know if this is the desired behavior.  It is an interesting
>>>| > idea
>>>| > to schedule "async" packets during iso in order to have a private 
>> iso
>>>| > stream.  However, in order to avoid having to put on flame
> retardant, 
>>>| > I
>>>| > will quickly say that I'm not proposing we make a change but I'm 
>> just
>>>| > trying to say that if you don't like what is currently spec'd there
>>>| > are
>>>| > a lot more possibilities than the two you list. 
>>>| >
>>>| > _____________________
>>>| > John Nels Fuller
>>>| > Software Design Engineer, Windows NT 
>>>| > Microsoft Corporation
>>>| > One Microsoft Way
>>>| > Redmond, WA   98052-6399
>>>| > Voice: (425) 703-3863
>>>| > Fax: (425) 93 MSFAX
>>>| >
>>>| >
>>>| > > -----Original Message-----
>>>| > > From:     Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com] 
>>>| > > Sent:     Friday, May 30, 1997 1:59 PM
>>>| > > To:     P1394@Sun.COM; 1394ohci-l@austin.ibm.com
>>>| > > Subject:     "Loose Asynchronous" vs "Loose Isochronous" 
>>>| > >
>>>| > >      I believe discussions regarding "asynchronous streams" and 
>> lost
>>>| >
>>>| > > cycle
>>>| > >      start packets have led both OHCI and P1394a to a "loose 
>>>| > > isochronous"
>>>| > >      interpretation which allows the link to receive isochronous
>>>| > > packets
>>>| > >      within the asynchronous period.  (In fact, OHCI mandates 
>> "loose
>>>| >
>>>| > >      isochronous" implementations.) 
>>>| > >
>>>| > >      But what behavior should be specified if an otherwise valid
>>>| > >      asynchronous packet is received during the isochronous
> period 
>>>| > > (i.e.,
>>>| > >      between cycle start and the first subaction gap)?  Assuming
>> the
>>>| >
>>>| > > specs
>>>| > >      are currently silent on the point, I think there are two 
>> basic
>>>| > >      options:
>>>| > >
>>>| > >      1) Continue to say nothing in the specifications ... the 
>>>| > > reception of
>>>| > >      an asynchronous packet during the isochronous period is 
>> clearly
>>>| >
>>>| > > the
>>>| > >      sign of a broken bus.  Don't force implementations to check
>> or
>>>| > >      correct.
>>>| > >
>>>| > >      2) Require that links NOT issue an acknowledge packet. 
>>>| > (Issuing
>>>| > > an
>>>| > >      acknowledge would likely interfere with isochronous 
>>>| > arbitration.)
>>>| > > In
>>>| > >      the case of OHCI, the link could pass the packet up the
> stack 
>>>| > > with an
>>>| > >      event code of ack_missing. 
>>>| > >
>>>| > >      Does anyone feel that the packet (assuming it passes CRC) 
>> must
>>>| > be
>>>| > >
>>>| > >      accepted by the link and processed as if received during the
>>>| > >      asynchronous period (with the exception of the ack generation
>) 
>>.
>>>| >
>>>| > >
>>>| > >      Feedback requested,
>>>| > >      Jerry Hauck
>>>| > >      Intel Corp.
>>>| > >      jerry_hauck@ccm.sc.intel.com 
>>
>>
>>
>>
>>
>     
>--
>Colin Whitby-Strevens             email:colinws@bristol.st.com 
>SGS-THOMSON Microelectronic       tel: +44 1454 611500
>1000, Aztec West                  fax: +44 1454 617910 
>Almondsbury
>BRISTOL BS12 4SQ
>UK
>
>Text item: External Message Header
>
>The following mail header is for administrative use
>and may be ignored unless there are problems.
>
>***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
>
>Content-Transfer-Encoding: 7bit
>Content-Type: text/plain
>MIME-Version: 1.0
>X-Mailer: Pronto Mobile [wrq Ver 2.1]
>Subject: Re: re: RE: Re[2]: "Loose Asynchronous" vs "Loose Isochronous"
>X-Priority: Normal
>To: ewa@apple.com, DavidW@bangate.compaq.com, P1394@Sun.COM,
>        1394ohci-l@austin.ibm.com
>From: Colin Whitby-Strevens <colinws@bristol.st.com>
>Message-Id: <199706031700.SAA19302@buttercup.inmos.co.uk>
>Date: Tue, 3 Jun 1997 18:00:02 +0100 (BST)
>Received: by buttercup.inmos.co.uk id SAA19302; Tue, 3 Jun 1997 18:00:02
> +0100 (
>BST)
>Received: by hawkweed id SAA20799; Tue, 3 Jun 1997 18:00:07 +0100 (BST)
>Received: from hawkweed (hawkweed.bri.st.com [192.26.234.4]) by saturn.Sun
>.COM (
>SMI-8.6/mail.byaddr) with SMTP id KAA13727 for <P1394@Sun.COM>; Tue, 3
> Jun 1997
>10:00:53 -0700
>Received: from saturn.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1)
>     id JAA18464; Tue, 3 Jun 1997 09:59:29 -0700
>Received: from sunmail1.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3)
>     id JAA23373; Tue, 3 Jun 1997 09:59:35 -0700
>Received: from Eng.Sun.COM by scsi.eng.sun.com (SMI-8.6/SMI-SVR4)
>     id KAA03629; Tue, 3 Jun 1997 10:02:37 -0700
>Received: from scsi.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
>     id KAA11606; Tue, 3 Jun 1997 10:00:06 -0700
>Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/ma
>il.bya
>ddr) with SMTP id KAA20245; Tue, 3 Jun 1997 10:19:08 -0700
>Received: from mercury.Sun.COM by imssc2.sc.intel.com (8.8.4/10.0i); Tue,
> 3 Jun
>1997 17:28:44 GMT
>Received: from imssc2.sc.intel.com (imssc2.sc.intel.com [143.183.152.8])
> by prai
>rie.sc.intel.com (8.7.3/8.7.3) with ESMTP id JAA20545 for <Jerry_Hauck@ccm
>.sc.in
>tel.com>; Tue, 3 Jun 1997 09:28:25 -0700 (PDT)
>Return-Path: colinws@bristol.st.com
>

--
Colin Whitby-Strevens             email:colinws@bristol.st.com
SGS-THOMSON Microelectronic       tel: +44 1454 611500
1000, Aztec West                  fax: +44 1454 617910
Almondsbury
BRISTOL BS12 4SQ 
UK
From:	Dream Ku [Dream@via.com.tw]
Sent:	Wednesday, June 11, 1997 2:57 AM
To:	'1394 OHCI Reflector'
Subject:	IntEvent.phy question

	
	In OHCI 0.93 Table 6-1 it describes the phy bit - "Generated
when the PHY 
requests an interrupt through a status transfer.". 

What is the meaning for "an interrupt"  ? Does it mean that the HC will
set IntEvent.phy
bit when the bit 3, PHY_interrupt bit defined by the P1394A Draft 0.08
on tabel 5-11, is
set by PHY through a status transfer or one of the status bits (0-15) is
set by PHY ?

If the answer is the provious case then how about the IntEvent.phy for
older PHY.

What's the SW behavior when IntEvent.phy is set by HC ? 

Dream  Ku
----------------------------------------------------------------
Software Team, VIA Technologies, Inc.
8F, 533, Chung-Cheng Rd., Hsin-Tien,
Taipei, Taiwan, R.O.C.
Tel : 886-2-2185452    Fax: 886-2-2185453


From:	PIPHO, RANDY [RANDYPIPHO@TX.SLR.COM]
Sent:	Thursday, June 12, 1997 1:12 PM
To:	'OHCI Reflector'
Subject:	STORE VALUE Descriptor

>The paragraph (9.1.6 of 0.93) defining the 
>STORE VALUE command should indicate that 
>if it is used it must be followed by one 
>or more OUTPUT_X descriptors.
>There is some confusion about this since a Z 
>value of 1 can imply a STORE VALUE can be the
>only descriptor in a block. 
>
>Regards,
>
>Randy Pipho
>
From:	Allen.Tsai@jksmtp.nsc.com
Sent:	Sunday, June 15, 1997 11:36 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Subscription: 1394 OpenHCI reflector






Please add my email ID (allen.tsai@nsc.com) into 1394 OpenHCI reflector. Thanks.
Best Regards,
Allen Tsai


From:	Jeff Fisher [jfisher@aeronix.com]
Sent:	Monday, June 16, 1997 10:54 AM
To:	1394ohci-l@austin.ibm.com
Subject:	OHCI Reflector List Request


Dear  OHCI Reflector Coordinator,

I would like be added to your reflector list concerning the 1394 OHCI.  My
email address is jfisher@aeronix.com.  Your cooperation is appreciated.

Thanks,

Jeff Fisher

                \\|//
               ( o o )           
 ~~~~~~~~~~~oOOo~(_)~oOOo~~~~~~
Jeff Fisher
Aeronix Inc.
1775 W. Hibiscus Blvd. Suite 304
Melbourne Fl    32901
(407)984-1671 x-19 - voice
(407)984-0366 - fax
From:	Lee Wilson/Austin/IBM [Lee_Wilson/Austin/IBM@aussmtp.austin.ibm.com]
Sent:	Monday, June 16, 1997 9:46 AM
To:	1394ohci-l; 1394ohci-l
Subject:	New Reflector Folks

Hi,

    Over the last week, a large number of people have been added 
to the reflector.  Please note that the accompanying ftp site is:

  ftp://www.austin.ibm.com/pub/chrptech/1394ohci/

   On this site you will find specs, presentations made at our conferences
and logs of back reflector traffic (OHCI_May.pst is a Microsoft exchange 
file and OHCI_May.txt is a text file of this reflector traffic).

    Please utilize this resource in addition to tracking new events on the 
reflector  (there's a lot of info. and history out there).

    Best Regards,
    Lee Wilson
From:	Neil Morrow [nmorrow@ti.com]
Sent:	Tuesday, June 17, 1997 2:48 PM
To:	1394ohci-l@austin.ibm.com
Subject:	fwd: OUTPUT_MORE for Iso Transmit Contexts



Best Regards,

Neil Morrow
Texas Instruments
PCIbus Solutions - MSP
PH: 903-868-5481
FX: 903-868-5980

------------------
Original text

From: Neil Morrow <nmorrow@ti.com>, on 6/17/97 9:18 AM:
To: leew@austin.ibm.com


All,

OHCI:  Section 9.1.2 and 9.1.4 detail the OUTPUT_MORE and OUTPUT_LAST
descriptors for isochronous transmit.  From the command description,
it is implied that the header of an iso packet can be stored in a
buffer pointed to by dataAddress.

The OUTPUT_LAST description seems solid in that a skipAddress is given
if it is the first descriptor in a zblock; however, the OUTPUT_MORE
description does not provide a skipAddress.

Please clarify.

Best Regards,

Neil Morrow
Texas Instruments
PCIbus Solutions - MSP
PH: 903-868-5481
FX: 903-868-5980
From:	Nishimura Yoshihiro [nisimura@ipdc.sanyo.co.jp]
Sent:	Wednesday, June 18, 1997 1:27 AM
To:	1394ohci-l@austin.ibm.com
Subject:	subscribe

subscribe nisimura@ipdc.sanyo.co.jp

     NAME   : Yoshihiro Nishimura
     COMPANY: SANYO Electric Co.,Ltd.
     PHONE  : 0584-64-4929 japan
     FAX    : 0584-64-4737 japan
     E-Mail : nisimura@ipdc.sanyo.co.jp
From:	Young, Mark [MARKYOUNG@TX.SLR.COM]
Sent:	Friday, July 18, 1997 1:43 PM
To:	'1394 OHCI Reflector'
Subject:	32-bit access *only*

Para 1.5 (c)
	"access of 32-bit entities in either system memory or on the
Host Controller must be endian neutral and atomic."

We need to add a clarifying sentence to this. I was 'bitten' here!

"No 8-bit or 16-bit accesses to Host Controller registers are
supported."

It means, in reality, that 'C' bitfield structures can *not* be mapped
over any OHCI registers, since they are endian-specific and because
compilers will produce byte-accessing instructions. 

Byte accesses will not work when the hardware will flat-out not support
anything but 32-bit accesses to the registers. 

Maybe everyone else understood all of this from this one measly sentence
but I only recognized it after a lot of code had been written...


Regards,
 Mark Young
 Solectron, Texas
 Email: MarkYoung@tx.slr.com

From:	MILES_THORLAND@HP-Loveland-om10.om.hp.com
Sent:	Friday, July 18, 1997 3:33 PM
Cc:	1394ohci-l@austin.ibm.com
Subject:	Unsubscribe

     Unsubscribe Miles_Thorland@hp.com

     
     
From:	cwwang@opti.com
Sent:	Monday, July 21, 1997 9:01 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cwwang@opti.com
Subject:	subscribe into the reflector

Hi,
  Please add my e-mail address (cwwang@opti.com) into the reflector.  Thanks.

Michael Wang at OPTI Inc.
From:	klashman@meow.East.Sun.COM
Sent:	Monday, July 28, 1997 3:19 PM
To:	1394ohci-l@austin.ibm.com
Subject:	OpenHCI 0.94

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 16

1394 OpenHCI version 0.94 is now available at the ftp site:

ftp://www.austin.ibm.com/pub/chrptech/1394ohci/ohci094.pdf

Attached to this email is the editor's checklist of 
some of the more significant changes from .93 to .94.

Diana

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Member of Technical Staff                                |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
----------
X-Sun-Data-Type: PortableDocumentFormat-file
X-Sun-Data-Description: PortableDocumentFormat-file
X-Sun-Data-Name: revs94.pdf
X-Sun-Encoding-Info: uuencode
X-Sun-Content-Lines: 218

begin 600 revs94.pdf
M)5!$1BTQ+C(*)>+CS],-"C(@,"!O8FH*/#P*+TQE;F=T:" Q-C8Q"B]&:6QT
M97(@+T9L871E1&5C;V1E"CX^"G-T<F5A;0T*2(F45UMOU$H,?M]?80GI*$&;
MD,E]D4""TG(1B*.R#^A05,TFL[N!)+-D)BS+K\>>))ND+0]'HM09SWSVV)_M
M*8/=XLGK3PQV:L&@@(4''L3,AV3E0R,6V\7+]>+)E0\,UML%(ZT'^"OQ(8AA
M7>'^'?ZL,_KON+ ^R#KGIR6\:\L3^.D2V&J5V.MOB]!W_23 P^M7"^M?OA.(
M*+<0D@[-&5@?HA 2_(6XUHWU262ZD#74;;41C0+>"-AP)7+ 1<]=!2!0)1I.
MNVYL0GIR%7:>KMPH3L#QR=P7:VVO?(MO2C3Z%-X72I/I;,_KG5"P;6R66K*"
MCV\NWG:XH"4)H?UU_6Z\O9.Z:90BJ,L0VP"KWL5'ML.B-$VL7*BL*0ZT: X[
MGNM[Z=D1S3? '-]V?+:*K!\M+XOM"7CV_3:3U:$46BS-UT'4>5'OX!_SI4\'
M :)I9 /'0N_A)O#]G90Y7%Q?0%'#1N*BW@MC,0*'#0Y:>\%ST0"O<\BYYK I
M9?8=;JQB2_LQGH7"8(H;VZ7H.>9L&@2=L\P-7+PK.NM'GE6)VEQ5%Y60K88M
M>I/C!9S#'G."7-'-R8YCRS5>K!_W )'M!)[G6>^EQ%U<G>IL#P>\E<T\2^@N
MJ\6NEHW(E\;11E0<+T7_E*3-A#\%C99(&\=/T*G+BK3%;[)OL\C:(5Z6"44D
MX0H"W]D4&LAS70AU=LT*W' )J9LLZ=K>-&+,<V-:C("-:7YS@5%"0C<B$X7M
M1]9/,H;<F5[$I"87-T$0UV3^<&BDS>)^;PXZD_G@ T7:1-DP(G#\^XZ08N5T
M'I++*PQFV'GFN\&0(Y[G\'9-?!7&+WW;UICQIJV[8.)J3*O&^"TJ["CJ4S2U
MU@'=A7@8@8R5?0T94D[B6M19V>8"!K(,6T!IKEOU$,L"EQ''#$F(4^I /$!O
M,F[[K(\>UTC:LNAB#12:U/%O;"0Q:M01U%ZV90ZUU)@CG@/RFV-E&M<-@.U9
M0.5# !P_.B1:)?XIH2>T[5/2%RFO"< 4*9@,3G*\.4'6-@U>UH1JV^H6T5BP
M"NG"V F;7$'%3[ 1 W>2@0]G@]@B/&P1V#T[T[:36J-YK 9)!\9K# DI9;V[
M'0DXC7FWRG 5.TESN[%]SVJW4*'[IFXS62O,H*@S(N@)%.8-P[HOU+T6XO6.
MB:8"+#43XHT05)^ZD7F;$;.E.0L'B8LNP"NA>5%B*9:4C!.5\MMKZK<'A+&C
MQ!J+8$*$.V%'!E#(-<:PZRLPU" &N>Z&@&YXK:I"_RUW Z&K0N$5=[<FAQQY
M72K9Y:3'0K[T^1GKE3;OD4L<P]D4^M0QV8YF+<YTR'./S$K<B0W=T!*[+9[^
M#3\)E)>M,*8WE $L, H*AV%<8$Y,:YXA(ZX;]L@=FZ<TP'AGI4#VYOV4BOL9
MS=PX\OM!6U25R NN17GJQF,_RD(W3=-^#QSWF,[<E(WJ2H&J%'%P&D\:TK!C
ML&KP>J.QRU;_WR:UF!&P-QN[-"_O\2+H4SJ$^#\Z^<C,<8F\WP&+G<U)XX@I
M<9I0;5(\%;*F%$3R'2\I$TBLDBJ8^%P,)8P 9L^O^UT@[,V67)DYTIR> C#V
M^3,XSG,4/.]O)Q@>\#&<-949/3-D64IRX$B#79O7"/4>M+YMB9WH:B[H"3 C
M07!NCLG5U=4E/'OV'%"ZG._Q^SVU1!ZK Y:W,*9-M5,'HRI_<0VO/KS #3]:
M@<Z9%)BZ[5JTS+"7J3O&PQZ8.EZ#A[I64J*;X%#55/P7#(^5@\26DL,1BT6H
M)>SQ$ZI6Z;[,9@^;C]?W.@W.(-S0&5"GQP_VB,XAFOQFW/\ZE/14P*=,-UTQ
MF&5;F;=#@"?Q:OW4[0>%W&J< /@4Q+A36VY5UP\)8,*"_I989?H!+PW4GF8.
M+TND&V4UMHXP#(K.$RKO8:'O4H.)Z$RTRS7VU]?X\P[KXAL^.6,X0N"F,7R 
M+U\]R!=8@L@QUX^@(CE.$C>)H%R\?(R%'L)J19^5D>,DI7U&%P78!28GS>?T
M,*VD$9TQ:EHG^:P+\!N7>[OTN_^<[_ Z\\,.[QX^BT=\E*>Z"*?DH"-YIL._
M+\XZE&>ZR!MU*,]T;(+)YIAA/.I(GNG"T1[),YT_VB-YJ@O2$9/DF2X>,4F>
MZ<(1D^29CHTY(7FJ\],1D^29+AXQ29[I@A&3Y)ENDB/_3H[8)$?L3H[8)$?L
M3HY8,&*2/--YHY\D&]T? 08 7Y7BH@IE;F1S=')E86T*96YD;V)J"C,@,"!O
M8FH*/#P*+U!R;V-3970@6R]01$8@+U1E>'0@70HO1F]N=" \/ HO1C(@-" P
M(%(*+T8T(#4@,"!2"B]&-B V(# @4@H^/@HO17AT1U-T871E(#P\"B]'4S$@
M-R P(%(*/CX*/CX*96YD;V)J"C$P(# @;V)J"CP\"B],96YG=&@@,3,W-0HO
M1FEL=&5R("]&;&%T941E8V]D90H^/@IS=')E86T-"DB)C%9M;YM($/[.KQCI
MI!.<#&&!!7Q23[JF39LJ4:O4I_O@5-4&-H:&M^[B\_E^_<TL-N XE?HASL"S
M._/,S+.S,-A8%^\^,]AHBT$)E@\^Q"R 9!F DM:C]7IE75P%P&#U:#%"?<!_
M20!A#*L:UV_P;Y71S\ZR;]LF%_L%?-A6>PC2!;#E,G%6WZPH\((DQ,VK-Y;]
M26PD!- ^0D08AC-N X@Q>!R07SOTH@6!/KC,8W%B-MZ'8;R!I<M\@E:_63;S
MO= +Z8E#X(5A2.O6]IVL6X=Q^Q_ZD8YO@Z@JJ&73EVU#@5=9FTN([L. %Y<@
MFARSI2WQ;,OU'5RVG<-\>Z_*3=&_$;UXVXB'2L)#V7O.E]4'R^7@1B._7CQ 
MY(9GO'\%0C*7#40GX/KNLA!-(ZM;H9_@U:L_,.CMMNI+>DWO: /%,'G960'\
MS#FY9FZP.);D0&)\QDWL%!V)1%X\.%G;C70";N^@[:A$HH*NV.LR$]5?72?5
MZW9K2D0%VI2ZEPIR60OU5#8;Z-N.2MH53FP/>W"E[MI&2U.C$[9*-!OI'=/B
MQY;].+5#/<^XS[I]Y'YO*_E]6RJ9WSOPZ#!FBU(U4FO(VJ97;64RX(<,',[M
M%YJXMKD7.6Z8<-^6=5<(7?XGH2]$C[M[54KT)E!##2K\04+>-A(>6P4/3L#L
MK=X#VB)[^IJC6KY*I=HA$,# <I"7HBTF-I_G2_OJ4FNLZE@BYJ6'$A&OERIT
M>::KM?UGGH.6F'9^4]9E;Q2>4??V626'5T1ZJR7L+O*MJ%S*5)H4]UA(%I/&
M];V#Q&^?G0NB5TGWK+=K>_)ARH2BZ37,=BO4"M3BB<X4KFO;>FK F.>\ 4H^
MJ^7@E%0G-(@#71=0HH7H\ VFW;3]H5]]46HHFZS:YDCGZOKJXUG)US8*6RH<
M+$EK1*2QJ9F@NO2%-,EH/(_H!4MXUM?8?H$_TN=>\-.=*H2BDZ5E#[H72!TY
M^S272#9Z ;I][ \X(LV%F$).X7Y6&$8779TM8+,PFJC*YNFK[G+3;>_,RPA3
M^(<]%+NA@_^"WG9=JWJ9TVM:AD(I,JBWNC]B.")H8#>XIGO"MWB.M-']\3A3
MCW0G97XN]K5)BZ,,?-^WM50E3A4<CYMMF9O\T8'K>WX8T+U#JY.#9$9Y58*H
MX,B73895[<>:PM#I!CJAQ$:)KD#NI!P4=F;Z/AT5Z,O:M(0FB"@IE]T%B@$7
MG6G)'ZB\O\1@IE<MU0P[JG?$2. @S5^2.[6*NRQP7!8ON=VU.)WROU798[DP
MY>,@A@& W8  [ HD@@MVA6S.9TGY"'FIZ;;*%\<]Q.C@A9HO\'A1@8RN.]GD
M+\^=D=]S=;R@+U+KG1&K2S<J5DSCMP,RQ5+*$JNF!D'C29X)'_/H5+O!!^V=
MWG@_C/T#?5,;;SY]'B[HN2>22#I.E:X2V&GQR5Q9L$-BU')N6OYYWV0W=_+[
M<-4/I^WB*AH^@9:>CY%X,+A<.<O -A\$['>XP5N%[L&LH"L.E:X<EMIM#1_?
M7UZ#[RU#H,.#1G3P>?BL<E,OY2FXP304<'2;+Y5?4!,\31,;!UBF2G,WF\UO
M5UB.=_CW ;^<OJ'3&'80>FD,M[#^XD-N\0A2WPLXU&0F/O,2#I7U^C>+,7Q>
MTF,]V'Y ZPS&0X:NQHWF:;Z7WJ2<MAB8WI,]8B&'.$F.8>G_X?%T131$/ZZ(
MGON/@WCT3_8<XTM_Q,@^P=C$B^PY%L431O8)-HL7/8L7SN*%S^*%6-H10_L$
M8^F$H3W'@GC"R#[!HHD+V2<8F[B0/<=8,G$A^P0+IWADGV"S7C+_M"[I%"X]
M1/M?@ $ FR8M5PIE;F1S=')E86T*96YD;V)J"C$Q(# @;V)J"CP\"B]0<F]C
M4V5T(%LO4$1&("]497AT(%T*+T9O;G0@/#P*+T8R(#0@,"!2"B]&-" U(# @
M4@H^/@HO17AT1U-T871E(#P\"B]'4S$@-R P(%(*/CX*/CX*96YD;V)J"C$S
M(# @;V)J"CP\"B],96YG=&@@,34Y-PHO1FEL=&5R("]&;&%T941E8V]D90H^
M/@IS=')E86T-"DB)?%;;CMLV$'WW5PQ0H)""E2)2UL4%6J"7I$F0=(O&;[O%
M0I9H6XUN%:6Z[M?W#"7KLDG[L-X1AQP>GCDSI*#3YN7/'P6=]$903AN// J%
MI&@GJ56;X^:'_>;E:TF"]L>-8*]'^!=)\D/:EYA_PM\^Y9_+QOI05UERO:-W
M?7$E&=^1V.TB>__'9BM=&?E8O/]I8_V:G!3Y5!]IRSYL9\)*"K%Y*#GN@Q6X
ML>WX4>!9J2T"ZYH6ZF/=MZFB7%/=='E=)85+E!^IJCO*RZ90I:HZE0%XDI$'
M7UHD;7Z\$B*$)L+]T9:!==2J<^W?]^^ VA%N[/L&5N#N&(X9$V%DQKKD0*DC
M>#R@:?C!.MC2LWK]2U\>5(L-$9&Z&M0\^C(X^Z]?4UT1)@E,&MS#ADY CC^$
MX-"!(Z3MB' 76+H^=K^9.*WNS9%:G?:?H61BA  S$LSDND[/-/%#75X:-#QP
M8IZ*.LE R"7OSM2=%65)E]"C[X>JR"BOZ-7W]E98/[Z!G=9E7IT6P727M"/J
M_8OUOM@!-%[LG56W&6-5WY#NFZ9N.XZ15&0@_-VI%DE"&NKTTS)M=W1.F)N_
M_F^VV3E8)./!NJW' AE:?_$J5;$"KG5/67W# .[53/>:.NGB$#@#9#6*HSLG
M'37GJ\Y31&[5G[W2G::D52.NM.A!XH*)D&,8:?[9)\44P^1.L=1.N<9A*$TJ
MSN,PGF1.7:$J#GFG%[%8!:'#F 1$P$Z4PM>H-V=2+R0ED9TRJ3*8/GW[[7=F
MK.Z[IN^>BD1W+V@QX;^"3ZG=V[%GU?7[&NP[-$IY%+'YU48L@YH231=5%/\)
M>8KZ%A*J-)^\ZA V:9HB5YJKXNUOE!2Z7C&(/)A,L)S.%]+GI"BH&80U)A;,
M7>C8UB684* ":,>*>AJPYIB2]<:A57%T\@QY3+3Z#*L<L;*R4&/-J[:E1R:;
M=H\V"[/,M>8P9K<"9UB$0(5%2+?OA5:280>>-U"#H]V_7\SDPCI19+;S0V'Q
M+%11V9B4S5^/5F*(;L"7(E;%HSU'B< ,(O@>-'K_P<G+4F5YTBGJ-4KY6+?4
M).DG6W@6*#A#5T#",>PPL-QE&#F%T4UF(#!M[<!N1GV5*49<K;3-R_PI,RRS
M2UX4*]V5R=5\MZKK6RY>3EGWA%A1K\_/H@40LP$BI)2&0)R@Q/GY((F^5J!7
M=RB/4E/SJ0,W75IGBKY_M*<XG )<%RW%7^S/ H1CG"?ZP.[CUI');63HLMNA
M@?N @U6.YWI\?5V D&$<3,>9*K^&^%LNZ8JKJD$C>-(76P!]PW=6WI:W,M=W
MW'R,C>Y5<:L=T$-27/G_J+:>._B(V1LVUIA/2.13 V/H@Q!7WYG2&S(LK.%6
MX9&DO0%$XB#<YQW0K )_%Q9&W1?9G 1SGDL.J1T4&F^5%<!YN Y+SC9N1FUB
M?O&&BJ?BX=PQWN[:J"?5MG5K!Z'U^3WZ8,7N=A#?I*'Y3$:U+"D&<[@-H3?V
MW4ID:Q;,)J_VV.=G_+U#B_P#%WQ(%Z0T#ND#/?SN4;;Q@\"5@D3@N3&5&[1H
M-X['SV+SPPM^S<ROC6GV^.* KF=0@DMD!#7P(K=NZ(G500>"@I&@N< SI5.T
M-$X#0>N0KQG!A3NL\!<ELN-RO]N.9-U_0+W<OQ_[(6OHL"A\W:@4-X+I0&N5
M#'U@3L@4VA]; ',ZMQ)^!ZSHYD;00ENXT""/[@X-%=T\NWV;N8XS(UGUG6C<
M].7K[?!0W+D>M![(^>;>VSO4SP'/"O$-O4>#Y4I*(<83KHAC:XO80N>]?_/C
M6^1UYQ/+'L9VC#L^0)W8C8.8G$5@X.0W 7V%#A/$<60QTVUN'@HWU01;BF)7
M!I $FYYPHV#0@Q#XCOBS'&Q/\CSC"WP!A4T+AZ_%6AZ) UYBW#S.]N3S PH1
M>]R6_X^?ZQG;8??;C.WS^"$@W^*SO?*)>/:)>.4+=N'D8WOEB^:8;*]\_AR3
M[95/+&**=<SM;H[)]LH7S1RQO?(%WNR#O?+)&0O;*Y\W8V%[Z?/C&0O;*U\X
M8V%[Y=O.6-A>^19<^\^XE@NNY3.NY8)K^8QK&<Q8V%[Z1#SOQ_;*%\[[L;WR
M;>?]V%[YY+P?VRN?-Y^=[97&9RC1B.1? 08 RM2\$ IE;F1S=')E86T*96YD
M;V)J"C$T(# @;V)J"CP\"B]0<F]C4V5T(%LO4$1&("]497AT(%T*+T9O;G0@
M/#P*+T8R(#0@,"!2"B]&-" U(# @4@H^/@HO17AT1U-T871E(#P\"B]'4S$@
M-R P(%(*/CX*/CX*96YD;V)J"C$V(# @;V)J"CP\"B],96YG=&@@,30P,PHO
M1FEL=&5R("]&;&%T941E8V]D90H^/@IS=')E86T-"DB)=%9+;]M&$+[K5PS0
M"QF8%'?Y#I "<>*T3N,DB)5>["!8D4N)"<D5N%05]]=W9DGS8:L'2;,[.^]O
M9L1@MUK_<<M@IU<,2EAYX$'$.,0IAU:NBM7E9K5^QX'!IE@QXGJ /S$'/X)-
MC>]W^-ED]'5:63>JR<7#!;P_5@_ DPM@:1K;FQ^K@+L\]E%X\W9E?18["0&H
M @+BH3FCED.$QB-.>JW496YT06P/'.:R*#:B=&T4AC!>WEFW&YLEUJ<O5]__
MMID?6J\_?+T"O1=5!8WJ8"NAVTM0#3J52YVUY:%3+90-B/EY6ZGLIVM_V[Q?
M.2$X?J\[==%UV_$]S[.DS4+K5R>;'#(B'[)*WH@NV\,6PX5MV>D+J!6Q_J$O
M:7L67&^>/+YJQ+9"EQ0)@,]ZDR;,Q#]CM5!5I6P>6J>RV4$GMI Z\07 [5X=
MJQQJXX!JR$IDK&QLS$%9RQ:CGVYO.]%VO:W-"V/"=X/!1"N-?CNU5)N# V4!
MI5:H]B#;4N6 $6M,8Z%:"9353#6=),6_.@U[87-O%O!6R@8.K<JDUC)WW87-
MT&5C6.V4&"P&ZM2EQN1V%Z [=>CKU>V5EDM[)'C:E^C=&%M?A%*CHY3;O#<9
MSI!S9[U5S;W/0T)*]\QG+ ;9-&)7&RS&'_AYCZC\ 9X;P0E\-XG@!NZ^>9"O
M.&,NXC\, C>!>L6Y/QVKU>4+ZIH)U>-KTS%WUBR!H0E(:,A5=JPQ=)D3+-W4
M'W 8NQ'S%V&\J41;%I08T?4I6B3GM#9X(*0,N< ^K@4J+1N1=:7-HR%L%T!A
M6[0:?MH,L2T/L%,H-W7 #(^$.N8Y6#L6I:&E3U ?=0=:=N;U^EW4CXC435D\
MM'E)?3H.#P\'0#)P*-V>J>/UQ\]?-]]OL'4I[L-A2S(.\UR6+AW JQ"!PT//
M$CDEJ5"P0-#U#$#(GB-]<-X?G#=8[W/0=-\SE<N7(+*?D(M.@&Q;TBJ:87"T
MLCNV#6:1C&UMSJTCXJ4@%04VV+WO1U4ULX5^(AAL!QWUK*MQ5D3G9L4H9I&:
M'?D8/9MX@_/!LZ'W13Z=- AOCA4!038K*5J\\)\--/0P&#W46'#LOFPOFCDF
M!\P@-!>0(2/C:# RV'+Z(+.2 NBQ*^",3L+FF98D1VDRU\>J*YVG F>!R!""
M 8T/'!BM%#@;M*R*Z[>Z_%<"=RBMIE3%$>LF8=<J<O_4[:G+#DKKDF;O:<W\
M-!#8 O<X]1C#L8=HSD@=1I2><;6W @<$"KV7:.9@!FPN[^USCEX2WGS*L?&)
M,2> 5Z]^-[4$,#6"P/GKTEQR),X8-9(^<W"(T"NBV"#*/0.A7IKU<*)H6IR+
M F=XN.8(,@0(MQ[T>0\/68FZFK[DV!LL#$UOT?VA7S@882T:7-=UWU6%FI#>
M##MC7%ZCVZ]'I7U(\TU]K&O1/M#NIS&HNV-!]2DHF1TBSFPX18WF64>-,$0\
M/T/PQ_^U/(4SP%4_=X$#K62*I<516:I&5$,:HD%.8Q[)"02F;&E?[ RT\8I-
M">NQ/L",]B<VR9#G];N@GWF!ZZ'5@/6&-W;*+;/ZV4OX@).*LD"@WZ'%PAA2
M-7SZ\\TU[IS4!S,EW308= YSU$G<)$S X7-L9A0'_(9%#),DMA[_U.#EXT8+
MT:4T<7F(^PKIV,/_46&_K!@C7DSGVAQBC]-#PPSQ_TDT$S7'N33=)"')&#;=
M$SWR_!"B.'XT3+_#<?DBZ,T_O@B>ZH\";]1/](+'DHG'D@4O3*.11_2"%P<3
M#^D%C\]X_ EO%FLXCQ5Y03+Y2?2"%TY^$KW@^9.?1"]XWDRGM]3I1Y.?1"]X
M?+)'])S'TRD&HA>\>+)'](+G3_:(GO,0)2./:,/[3X ! ._ +5$*96YD<W1R
M96%M"F5N9&]B:@HQ-R P(&]B:@H\/ HO4')O8U-E="!;+U!$1B O5&5X="!=
M"B]&;VYT(#P\"B]&,B T(# @4@HO1C0@-2 P(%(*+T8V(#8@,"!2"CX^"B]%
M>'1'4W1A=&4@/#P*+T=3,2 W(# @4@H^/@H^/@IE;F1O8FH*,3@@,"!O8FH*
M/#P*+U1Y<&4@+TAA;&9T;VYE"B](86QF=&]N951Y<&4@,0HO2&%L9G1O;F5.
M86UE("A$969A=6QT*0HO1G)E<75E;F-Y(#8P"B]!;F=L92 T-0HO4W!O=$9U
M;F-T:6]N("]2;W5N9 H^/@IE;F1O8FH*-R P(&]B:@H\/ HO5'EP92 O17AT
M1U-T871E"B]302!F86QS90HO3U @9F%L<V4*+TA4("]$969A=6QT"CX^"F5N
M9&]B:@HT(# @;V)J"CP\"B]4>7!E("]&;VYT"B]3=6)T>7!E("]4>7!E,0HO
M3F%M92 O1C(*+T5N8V]D:6YG(#$Y(# @4@HO0F%S949O;G0@+U1I;65S+5)O
M;6%N"CX^"F5N9&]B:@HU(# @;V)J"CP\"B]4>7!E("]&;VYT"B]3=6)T>7!E
M("]4>7!E,0HO3F%M92 O1C0*+T5N8V]D:6YG(#$Y(# @4@HO0F%S949O;G0@
M+U1I;65S+4)O;&0*/CX*96YD;V)J"C8@,"!O8FH*/#P*+U1Y<&4@+T9O;G0*
M+U-U8G1Y<&4@+U1Y<&4Q"B].86UE("]&-@HO16YC;V1I;F<@,3D@,"!2"B]"
M87-E1F]N=" O5&EM97,M271A;&EC"CX^"F5N9&]B:@HQ.2 P(&]B:@H\/ HO
M5'EP92 O16YC;V1I;F<*+T1I9F9E<F5N8V5S(%L@,SDO<75O=&5S:6YG;&4@
M.38O9W)A=F4@,3(X+T%D:65R97-I<R]!<FEN9R]#8V5D:6QL82]%86-U=&4O
M3G1I;&1E+T]D:65R97-I<PHO561I97)E<VES+V%A8W5T92]A9W)A=F4O86-I
M<F-U;69L97@O861I97)E<VES+V%T:6QD92]A<FEN9R]C8V5D:6QL80HO96%C
M=71E+V5G<F%V92]E8VER8W5M9FQE>"]E9&EE<F5S:7,O:6%C=71E+VEG<F%V
M92]I8VER8W5M9FQE>"]I9&EE<F5S:7,*+VYT:6QD92]O86-U=&4O;V=R879E
M+V]C:7)C=6UF;&5X+V]D:65R97-I<R]O=&EL9&4O=6%C=71E+W5G<F%V90HO
M=6-I<F-U;69L97@O=61I97)E<VES+V1A9V=E<B\N;F]T9&5F(#$V-"]S96-T
M:6]N+V)U;&QE="]P87)A9W)A<&@O9V5R;6%N9&)L<PHO<F5G:7-T97)E9"]C
M;W!Y<FEG:'0O=')A9&5M87)K+V%C=71E+V1I97)E<VES+RYN;W1D968O044O
M3W-L87-H"B Q-S<O+FYO=&1E9B\N;F]T9&5F+RYN;W1D968O>65N(#$X,B\N
M;F]T9&5F+RYN;W1D968O+FYO=&1E9B\N;F]T9&5F"B\N;F]T9&5F+V]R9&9E
M;6EN:6YE+V]R9&UA<V-U;&EN92\N;F]T9&5F+V%E+V]S;&%S:"]Q=65S=&EO
M;F1O=VXO97AC;&%M9&]W;@HO;&]G:6-A;&YO="\N;F]T9&5F+V9L;W)I;B\N
M;F]T9&5F+RYN;W1D968O9W5I;&QE;6]T;&5F="]G=6EL;&5M;W1R:6=H="]E
M;&QI<'-I<PHO+FYO=&1E9B]!9W)A=F4O071I;&1E+T]T:6QD92]/12]O92]E
M;F1A<V@O96UD87-H"B]Q=6]T961B;&QE9G0O<75O=&5D8FQR:6=H="]Q=6]T
M96QE9G0O<75O=&5R:6=H=" R,38O>61I97)E<VES+UED:65R97-I<R]F<F%C
M=&EO;B]C=7)R96YC>0HO9W5I;'-I;F=L;&5F="]G=6EL<VEN9VQR:6=H="]F
M:2]F;"]D86=G97)D8FPO<&5R:6]D8V5N=&5R960O<75O=&5S:6YG;&)A<V4O
M<75O=&5D8FQB87-E"B]P97)T:&]U<V%N9"]!8VER8W5M9FQE>"]%8VER8W5M
M9FQE>"]!86-U=&4O161I97)E<VES+T5G<F%V92])86-U=&4O26-I<F-U;69L
M97@*+TED:65R97-I<R])9W)A=F4O3V%C=71E+T]C:7)C=6UF;&5X(#(T,2]/
M9W)A=F4O56%C=71E+U5C:7)C=6UF;&5X+U5G<F%V90H@,C0V+V-I<F-U;69L
M97@O=&EL9&4O;6%C<F]N+V)R979E+V1O=&%C8V5N="]R:6YG+V-E9&EL;&$O
M:'5N9V%R=6UL875T"B]O9V]N96LO8V%R;VX*70H^/@IE;F1O8FH*,2 P(&]B
M:@H\/ HO5'EP92 O4&%G90HO4&%R96YT(#@@,"!2"B]297-O=7)C97,@,R P
M(%(*+T-O;G1E;G1S(#(@,"!2"CX^"F5N9&]B:@HY(# @;V)J"CP\"B]4>7!E
M("]086=E"B]087)E;G0@." P(%(*+U)E<V]U<F-E<R Q,2 P(%(*+T-O;G1E
M;G1S(#$P(# @4@H^/@IE;F1O8FH*,3(@,"!O8FH*/#P*+U1Y<&4@+U!A9V4*
M+U!A<F5N=" X(# @4@HO4F5S;W5R8V5S(#$T(# @4@HO0V]N=&5N=',@,3,@
M,"!2"CX^"F5N9&]B:@HQ-2 P(&]B:@H\/ HO5'EP92 O4&%G90HO4&%R96YT
M(#@@,"!2"B]297-O=7)C97,@,3<@,"!2"B]#;VYT96YT<R Q-B P(%(*/CX*
M96YD;V)J"C@@,"!O8FH*/#P*+U1Y<&4@+U!A9V5S"B]+:61S(%LQ(# @4B Y
M(# @4B Q,B P(%(@,34@,"!270HO0V]U;G0@- HO365D:6%";W@@6S @," V
M,3(@-SDR70H^/@IE;F1O8FH*,C @,"!O8FH*/#P*+U1Y<&4@+T-A=&%L;V<*
M+U!A9V5S(#@@,"!2"CX^"F5N9&]B:@HR,2 P(&]B:@H\/ HO0W)E871I;VY$
M871E("A$.C$Y.3<P-S(X,30P-C P*0HO4')O9'5C97(@*$%C<F]B870@1&ES
M=&EL;&5R($-O;6UA;F0@,RXP(&9O<B!3;VQA<FES(#(N,R!A;F0@;&%T97(@
M7"A34$%20UPI*0H^/@IE;F1O8FH*>')E9@HP(#(R"C P,# P,# P,# @-C4U
M,S4@9B *,# P,# P.#0U-" P,# P,"!N( HP,# P,# P,#$V(# P,# P(&X@
M"C P,# P,#$W-3 @,# P,# @;B *,# P,# P-CDX," P,# P,"!N( HP,# P
M,# W,#<Y(# P,# P(&X@"C P,# P,#<Q-S<@,# P,# @;B *,# P,# P-CDP
M.2 P,# P,"!N( HP,# P,# X-S@R(# P,# P(&X@"C P,# P,#@U,S0@,# P
M,# @;B *,# P,# P,3@V-" P,# P,"!N( HP,# P,# S,S$S(# P,# P(&X@
M"C P,# P,#@V,38@,# P,# @;B *,# P,# P,S0Q." P,# P,"!N( HP,# P
M,# U,#@Y(# P,# P(&X@"C P,# P,#@V.3D@,# P,# @;B *,# P,# P-3$Y
M-" P,# P,"!N( HP,# P,# V-C<Q(# P,# P(&X@"C P,# P,#8W.#8@,# P
M,# @;B *,# P,# P-S(W-R P,# P,"!N( HP,# P,# X.#@S(# P,# P(&X@
M"C P,# P,#@Y,S,@,# P,# @;B *=')A:6QE<@H\/ HO4VEZ92 R,@HO4F]O
M=" R," P(%(*+TEN9F\@,C$@,"!2"B])1"!;/#EB.&,X,SEC.3EA.61F.65E
M8C,P8SDT,C8P-C<W9C5C/CPY8CAC.#,Y8SDY83ED9CEE96(S,&,Y-#(V,#8W
?-V8U8SY="CX^"G-T87)T>')E9@HY,#8V"B4E14]&"CEE
 
end
From:	Allan Flippin [allan@issiusa.com]
Sent:	Wednesday, July 30, 1997 3:28 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Subscribe

     Please subscribe me to the OHCI reflector.  The Email address to
subscribe is allan@issiusa.com.  Thanks!
From:	wjshieh@sis.com.tw
Sent:	Wednesday, July 30, 1997 10:40 PM
To:	1394ohci-l@austin.ibm.com
Cc:	cmlin@sis.com.tw
Subject:	FIFO underrun in transmitting a broadcast packet

Hi, all,

OHCI spec. said that a packet shall be retried when
ack_data_error is received from the target node,
including ack_data_error's resulting from FIFO 
underflows.

My question is :
If FIFO underrun in transmitting a broadcast packet,
shall this packet be retried?

Thanks for your time and answer.
======================================
Whieh-Jen Shieh
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp. (SiS)
Phone  : 886-3-5774922 ext. 4314
Fax    : 886-3-5790651
E-mail : wjshieh@sis.com.tw
======================================
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Thursday, July 31, 1997 11:37 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: FIFO underrun in transmitting a broadcast packet

I believe this case is discussed in Section 13.2.3 of the 0.94 spec.  
The last paragraph of the section states that a FIFO underrun on a 
broadcast packet (for which no ack is received) is interpreted as if 
an ack_data_error was returned.  As such, the packet will be retried 
as governed by the ATRetries register and the number of previous 
attempted retries.

Jerry Hauck
Intel Corp
(408) 765-5528
jerry_hauck@ccm.sc.intel.com


______________________________ Reply Separator _________________________________
Subject: FIFO underrun in transmitting a broadcast packet
Author:  leew@austin.ibm.com at SMTPGATE
Date:    7/31/97 1:39 PM


Hi, all,

OHCI spec. said that a packet shall be retried when 
ack_data_error is received from the target node, 
including ack_data_error's resulting from FIFO 
underflows.

My question is :
If FIFO underrun in transmitting a broadcast packet, 
shall this packet be retried?

Thanks for your time and answer.
====================================== 
Whieh-Jen Shieh
Design Engineer
Basic Technology Group
Silicon Integrated Systems Corp. (SiS) 
Phone  : 886-3-5774922 ext. 4314
Fax    : 886-3-5790651
E-mail : wjshieh@sis.com.tw
======================================
From:	Joe Chou [joec@lsi.sel.sony.com]
Sent:	Thursday, July 31, 1997 3:01 PM
To:	1394ohci-l@austin.ibm.com
Subject:	IR ContextMatch Reg

For CycleMatch of IR ContextMatch reg in Figure 10-6 of OHCI 0.94 is not
matching
the description of Table 10-4 and the list of changes from OHCI 0.93 to
0.94.

I think the figure 10-6 have minor error for cycleMatch.
The cyclematch bit should from bit 8 to bit 26, not bit 25, so it
contains a 15-bit value.



-- 

********************************************
* Joe (Chen-Chi Chou), SONY Corp.
* Tel: (408)955-4555, Fax: (408)955-5180
********************************************
From:	klashman@meow.East.Sun.COM
Sent:	Monday, August 04, 1997 9:24 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: IR ContextMatch Reg

Yes Joe, you are correct.  IR cycleMatch should include bit 26 also.
Thank you for pointing this out!

Diana

>From joec@lsi.sel.sony.com Thu Jul 31 18:01:23 1997
>Sender: joec@lsi.sel.sony.com
>From: Joe Chou <joec@lsi.sel.sony.com>
>To: 1394ohci-l@austin.ibm.com
>Subject: IR ContextMatch Reg
>
>For CycleMatch of IR ContextMatch reg in Figure 10-6 of OHCI 0.94 is not
>matching
>the description of Table 10-4 and the list of changes from OHCI 0.93 to
>0.94.
>
>I think the figure 10-6 have minor error for cycleMatch.
>The cyclematch bit should from bit 8 to bit 26, not bit 25, so it
>contains a 15-bit value.
>
>
>
>-- 
>
>********************************************
>* Joe (Chen-Chi Chou), SONY Corp.
>* Tel: (408)955-4555, Fax: (408)955-5180
>********************************************
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Member of Technical Staff                                |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

From:	tsakurai@el.nec.com
Sent:	Monday, August 04, 1997 3:22 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Base_adr_0 register in PCI configuration registers

I have a question about Base_adr_0 register in PCI configuration
registers.

TableB-4 in OHCI0.94 wrote,
"This represents a maximum of 2-KB addressing space for the OpenHCI's
 operational registers.".

Why 2-KB ?

I think 4-KB, because PCI specification R2.1 wrote 
"Devices are free to consume more address space than required, but
 decoding down to a 4KB space for memory is suggested for devices
 that need less than that amount.".(Page 197, para3)


------------------------------------------------------------
Toshimi Sakurai  E-Mail  :tsakurai@el.nec.com
                TEL(NEC):8-00-01-941-5505
                TEL     :408-588-5505
From:	joec@lsi.sel.sony.com
Sent:	Monday, August 04, 1997 3:43 PM
To:	1394ohci-l@austin.ibm.com
Subject:	IR cyclematch field


I guess, we are clear about the cyclematch field is 15 bit now.
However, I am confused by the description of "cyclematchenable" in
table 10-3 and the "cyclematch" in table10-4.
From table 10-3, the 13-bit matching is good enough. From table 10-4,
it seems to me we need 15-bit matching for IR DMA context to start.

If we only need 13-bit matching, what is the 2 bits of CycleSecond for?
If we need 15-bit matching, the description of table 10-3 need to be modified
accordingly.




********************************************
* Joe (Chen-Chi Chou), SONY Corp.
* Tel: (408)955-4555, Fax: (408)955-5180
********************************************
From:	klashman@meow.East.Sun.COM
Sent:	Monday, August 04, 1997 5:04 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: IR cyclematch field

Yes, table 10-3 should say 15 bits are used.

Diana

>From joec@lsi.sel.sony.com Mon Aug  4 18:41:55 1997
>From: joec@lsi.sel.sony.com (Joe Chou)
>
>I guess, we are clear about the cyclematch field is 15 bit now.
>However, I am confused by the description of "cyclematchenable" in
>table 10-3 and the "cyclematch" in table10-4.
>From table 10-3, the 13-bit matching is good enough. From table 10-4,
>it seems to me we need 15-bit matching for IR DMA context to start.
>
>If we only need 13-bit matching, what is the 2 bits of CycleSecond for?
>If we need 15-bit matching, the description of table 10-3 need to be modified
>accordingly.
>
>
>
>
>********************************************
>* Joe (Chen-Chi Chou), SONY Corp.
>* Tel: (408)955-4555, Fax: (408)955-5180
>********************************************
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Member of Technical Staff                                |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

From:	cylin@sis.com.tw
Sent:	Tuesday, August 05, 1997 12:14 AM
To:	1394ohci-l@austin.ibm.com
Subject:	tcode error

Hi,

In OHCI0.94, Table 3-2, the meaning for evt_tcode_err is "A bad tCode 
is associated with this packet. The packet was flushed." While Sec. 3.4,
2nd last para. said "The Host Controller hardware shall allow any
IEEE 1394-1995 tcode to be transmitted by any transmit context." Are
these two statements in conflict, or the bad tCode includes only
those reserved by IEEE 1394-1995?

Thanks,



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	Joseph A Bennett [Joseph_A_Bennett@ccm.fm.intel.com]
Sent:	Monday, August 04, 1997 4:33 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Reading a PHY Register


Text item: 


I am a little confused about the text on page 48 of OHCI 0.94.  It is in 
reference to the rdDone bit.  The rdDone bit states that it is "set when a 
register transfer is received from the PHY."

    * Do I set this bit if register 0 comes in when no requests were pending?
    
    * If I am requesting another register, say register 4, and register 0 comes
      in first, do I set the rdDone bit?
    
    * If I have an outstanding request to register 4, and a bus reset comes in,
      do I still expect to get register 4?  This is a big issue, because
      software has already been told (via 1394.A) not to attempt multiple
      register requests.  If the request is "lost" due to a bus reset, software
      could attempt another request.

What I'm getting at here, is that the behavior of the rdDone bit implies a state
machine, based upon any outstanding register request.  This, then, implies some 
rules pertaining to bus reset.

To simplify things, I propose modifying the definition of the 'rdDone' bit to 
the following:

    If a PHY register comes in that matches 'regAddr' (the address sent on the 
    register read request), then 'rdDone' gets set, and rdAddr and rdData get 
    the data transmitted from the PHY.  If it doesn't, those fields do not get 
    updated and 'rdDone' does not get set.

This meets the criteria for register 0 coming in when not requested, and lets us
(OHCI hardware) not care about bus resets or outstanding register requests.

Joe

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: IR cyclematch field
To: 1394ohci-l@austin.ibm.com
Message-Id: <9708042243.AA00858@newt.lsi.sel.sony.com>
From: joec@lsi.sel.sony.com (Joe Chou)
Date: Mon, 4 Aug 97 15:43:19 PDT
Received: from moose.lsi (moose.lsi.sel.sony.com) by newt.lsi.sel.sony.com (4.1/
SMI-4.1/timg-1.1)
     id AA00858; Mon, 4 Aug 97 15:43:19 PDT
Received: by mail1.sjc.in.sel.sony.com id AA10169; Mon, 4 Aug 97 15:39:51 -0700
Received: by mail1.fw-sj.sony.com id PAA28342; Mon, 4 Aug 1997 15:39:52 -0700 (P
DT)
Received: from mail1.fw-sj.sony.com (mail1.fw-sj.sony.com [198.93.2.11])
     by ausmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id RAA13368
     for <1394ohci-l@austin.ibm.com>; Mon, 4 Aug 1997 17:40:41 -0500
Received: from ausmail1.austin.ibm.com (am01.austin.ibm.com [9.3.199.12]) by net
mail1.austin.ibm.com (8.6.12/8.6.11) with ESMTP id RAA35150 for <1394ohci-l@aust
in.ibm.com>; Mon, 4 Aug 1997 17:40:26 -0500
Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96])
     by ausmail.austin.ibm.com (8.8.5/8.8.5) with SMTP id RAA08352;
     Mon, 4 Aug 1997 17:40:14 -0500
Received: from ausmail.austin.ibm.com by thalia.fm.intel.com (8.8.6/10.0i); Mon,
 4 Aug 1997 22:43:11 GMT
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by fmm
ail.fm.intel.com (8.8.5/8.7.3) with ESMTP id PAA23687; Mon, 4 Aug 1997 15:41:16
-0700 (PDT)
Return-Path: leew@austin.ibm.com
From:	Jaideep Bhatia [jaideep@wipinfo.soft.net]
Sent:	Thursday, August 07, 1997 10:01 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Reading a PHY Register (fwd)


	This is in continuation of Joseph's mail about the rdDone bit. 
Similar problem is associated with the and IntEvent.phyRegRcvd . 
According to specs it should set whenver a ohci has received a phy reg 
data in the phy control register.
	Should this interrupt be generated for an unrequested reg 0 data 
transfer when a reg 4 data req is pending. If yes, then should it be 
generated once more when reg 4 data transfer takes place. 

Regards,

Jaideep Bhatia
Senior Engineer, R&D Hardware
Wipro Infotech Limited
88, M G Road
Bangalore 560001
India

91-80- 5588422,5588667	Ext:553
jaideep@wipinfo.soft.net

---------- Forwarded message ----------
Date: Mon, 04 Aug 97 16:33:00 PDT
From: Joseph A Bennett <Joseph_A_Bennett@ccm.fm.intel.com>
To: 1394ohci-l@austin.ibm.com
Subject: Reading a PHY Register


Text item: 


I am a little confused about the text on page 48 of OHCI 0.94.  It is in 
reference to the rdDone bit.  The rdDone bit states that it is "set when a 
register transfer is received from the PHY."

    * Do I set this bit if register 0 comes in when no requests were pending?
    
    * If I am requesting another register, say register 4, and register 0 comes
      in first, do I set the rdDone bit?
    
    * If I have an outstanding request to register 4, and a bus reset comes in,
      do I still expect to get register 4?  This is a big issue, because
      software has already been told (via 1394.A) not to attempt multiple
      register requests.  If the request is "lost" due to a bus reset, software
      could attempt another request.

What I'm getting at here, is that the behavior of the rdDone bit implies a state
machine, based upon any outstanding register request.  This, then, implies some 
rules pertaining to bus reset.

To simplify things, I propose modifying the definition of the 'rdDone' bit to 
the following:

    If a PHY register comes in that matches 'regAddr' (the address sent on the 
    register read request), then 'rdDone' gets set, and rdAddr and rdData get 
    the data transmitted from the PHY.  If it doesn't, those fields do not get 
    updated and 'rdDone' does not get set.

This meets the criteria for register 0 coming in when not requested, and lets us
(OHCI hardware) not care about bus resets or outstanding register requests.

Joe

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: IR cyclematch field
To: 1394ohci-l@austin.ibm.com
Message-Id: <9708042243.AA00858@newt.lsi.sel.sony.com>
From: joec@lsi.sel.sony.com (Joe Chou)
Date: Mon, 4 Aug 97 15:43:19 PDT
Received: from moose.lsi (moose.lsi.sel.sony.com) by newt.lsi.sel.sony.com (4.1/
SMI-4.1/timg-1.1)
     id AA00858; Mon, 4 Aug 97 15:43:19 PDT
Received: by mail1.sjc.in.sel.sony.com id AA10169; Mon, 4 Aug 97 15:39:51 -0700
Received: by mail1.fw-sj.sony.com id PAA28342; Mon, 4 Aug 1997 15:39:52 -0700 (P
DT)
Received: from mail1.fw-sj.sony.com (mail1.fw-sj.sony.com [198.93.2.11])
     by ausmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id RAA13368
     for <1394ohci-l@austin.ibm.com>; Mon, 4 Aug 1997 17:40:41 -0500
Received: from ausmail1.austin.ibm.com (am01.austin.ibm.com [9.3.199.12]) by net
mail1.austin.ibm.com (8.6.12/8.6.11) with ESMTP id RAA35150 for <1394ohci-l@aust
in.ibm.com>; Mon, 4 Aug 1997 17:40:26 -0500
Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96])
     by ausmail.austin.ibm.com (8.8.5/8.8.5) with SMTP id RAA08352;
     Mon, 4 Aug 1997 17:40:14 -0500
Received: from ausmail.austin.ibm.com by thalia.fm.intel.com (8.8.6/10.0i); Mon,
 4 Aug 1997 22:43:11 GMT
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by fmm
ail.fm.intel.com (8.8.5/8.7.3) with ESMTP id PAA23687; Mon, 4 Aug 1997 15:41:16
-0700 (PDT)
Return-Path: leew@austin.ibm.com

From:	Santhosh Kumar M [mskumar@wipinfo.soft.net]
Sent:	Friday, July 18, 1997 5:08 AM
To:	'ReflectorOHCI'
Subject:	Subscription 

Dear Administrator,

  Pls include me to the 1394 OHCI reflecter group circulation list. 

ThankYou

Santhosh Kumar M
Senior Engineer - Hardware
Wipro Ltd , Global R & D division
88, Mahatma Gandhi road,
Bangalore - 560 001
INDIA

Ph :  0091 80 5588422 ext 551
Fax : 0091 80 5586970



     
From:	swen@opti.com
Sent:	Friday, August 08, 1997 8:55 AM
To:	1394ohci-l@austin.ibm.com
Subject:	About Endian Processing


Hi,

    I read some presentation slides about Endian processing.
    However, I'm still confused about this topic. Is there any
    material I can get about this issue? Or maybe somebody can
    help me with it. I'll appreciate if I get any feedback.
    Thanks in advance.

Best Wishes
Arthur Wen
From:	patrick_yu@el.nec.com
Sent:	Friday, August 08, 1997 12:33 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: About Endian Processing

Arthur,

There was previous discussion on this subject.  Please find attached a 
re-collection of the discussion.  For more details, I suggest that you pay a 
visit to the OHCI web site and download two compilation of all the email traffic
in the past year or so.

Thanks.

Yours sincerely,
W.S.P. Yu
NEC Electronics Inc.

______________________________ Reply Separator _________________________________
Subject: About Endian Processing
Author:  <swen@opti.com (Arthur Shan Chih Wen)> at INTERNET
Date:    8/8/97 8:54 AM


     
Hi,
     
    I read some presentation slides about Endian processing. 
    However, I'm still confused about this topic. Is there any 
    material I can get about this issue? Or maybe somebody can 
    help me with it. I'll appreciate if I get any feedback. 
    Thanks in advance.
     
Best Wishes
Arthur Wen
     


From:	Young, Mark [MARKYOUNG@TX.SLR.COM]
Sent:	Monday, August 11, 1997 6:37 AM
To:	'1394 OHCI Reflector'
Subject:	IR cycleMatchEnable 0.94

Since cycleMatchEnable bit moved to bit 31 for IT in 0.94 spec, I think
the IR register (para 10.3.2) should also be changed to put
cycleMatchEnable in bit 31, swapping places with bufferFill. 

Regards,
 Mark Young
 Solectron, Texas
 Phone:  512-425-4253
 Email:  MarkYoung@tx.slr.com
From:	Richard Baker [artb@msg.tx.slr.com]
Sent:	Monday, August 11, 1997 1:38 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Reading a PHY Register


Jaideep, Joe,

Regarding the OHCI rdDone bit from Joe's email:
 
I think OHCI PHYcontrol register is intended to be a rather dumb interface to
the PHY registers - only enough functionality to allow software to read the
registers (and do all the bit banging required to get the correct data).
This is the way current silicon works.  The only times it doesn't work has
been due to other problems.  A couple comments:
 
1. I suggest that rdDone stay: "This bit is set to 1 when a register transfer
is received from the PHY."  No matter what caused the register transfer from
the PHY.  The rdAddr/rdData after a bus reset/selfID process should contain
register 0 address/data, and rdDone set.  (Or at least whatever is in
rdData corresponds to actual PHY data at rdAddr).
 
2. If the register read address is not the one requested, the software
must retry the request.  This is why there is separate rdAddr and rdData
fields in the register.
 
3. Best I can tell, a register read request to the PHY survives a bus reset.
So there should be no reason to retry a register read request because of
a bus reset.
 
The 1394A spec (P1394a 0.09) words about not issuing another request only
applies to bus requests - not register read requests.
 
There are some words about  "PHY response to multiple register read requests
when an earlier register read request has been queued is not specified".
 
I expect it will "be safe" to issue multiple register read requests to at
least some vendor's PHYs.  Software will just have to keep trying until it
gets the desired register.
 
Perhaps software should be allowed to retry the request after "some long time".
 
But, something is probably broken if it doesn't get a response to the read
request within a reasonable time.
 
So -- let's not change it.

//

Regarding the OHCI questions in Jaideep's email:

I believe that IntEvent.phyRegRcvd should be be generated for *any* PHY
register received, regardless of the reason.  So, an "unrequested"
PHY register 0 transfer would generate the interrupt, as well as a
"requested" PHY register 4 transfer.

Note that (some?) PHY's might consider the register read request satisfied
by any PHY register transfer, including a PHY register 0 transfer that
was not the register transfer requested by an OHCI PHY register rdReg
request.  It is up to software to figure out that the returned
PHY register is not the one it really wants, and to make another
request (via the OHCI PHY register) for the desired register.

//

Some of the 1394A work may conflict with this; but, I think to be
compatible with current PHYs, the read register function in OHCI should
stay rather simple.

I hope these comments are helpful.
 

Regards,

Richard Baker
 
Phone: 512/425-6205    FAX: 512/425-7023   email: rtb@artb.itg.ti.com
                                                 (artb@msg.tx.slr.com)
 
-- Solectron Texas --- System Design Engineering --- Austin, Texas --

 
Jaideep Bhatia wrote:
> 
>         This is in continuation of Joseph's mail about the rdDone bit.
> Similar problem is associated with the and IntEvent.phyRegRcvd .
> According to specs it should set whenver a ohci has received a phy reg
> data in the phy control register.
>         Should this interrupt be generated for an unrequested reg 0
> data
> transfer when a reg 4 data req is pending. If yes, then should it be
> generated once more when reg 4 data transfer takes place.
> 
> Regards,
> 
> Jaideep Bhatia
> Senior Engineer, R&D Hardware
> Wipro Infotech Limited
> 88, M G Road
> Bangalore 560001
> India
> 
> 91-80- 5588422,5588667  Ext:553
> jaideep@wipinfo.soft.net
>  
 
Joseph A Bennett wrote:
>
> Text item:
>
> I am a little confused about the text on page 48 of OHCI 0.94.  It is in
> reference to the rdDone bit.  The rdDone bit states that it is "set when a
> register transfer is received from the PHY."
>
>     * Do I set this bit if register 0 comes in when no requests were pending?
>
>     * If I am requesting another register, say register 4, and register 0 com
es
>       in first, do I set the rdDone bit?
>
>     * If I have an outstanding request to register 4, and a bus reset comes i
n,
>       do I still expect to get register 4?  This is a big issue, because
>       software has already been told (via 1394.A) not to attempt multiple
>       register requests.  If the request is "lost" due to a bus reset, softwa
re
>       could attempt another request.
>
> What I'm getting at here, is that the behavior of the rdDone bit implies a st
ate
> machine, based upon any outstanding register request.  This, then, implies so
me
> rules pertaining to bus reset.
>
> To simplify things, I propose modifying the definition of the 'rdDone' bit to
> the following:
>
>     If a PHY register comes in that matches 'regAddr' (the address sent on th
e
>     register read request), then 'rdDone' gets set, and rdAddr and rdData get
>     the data transmitted from the PHY.  If it doesn't, those fields do not ge
t
>     updated and 'rdDone' does not get set.
>
> This meets the criteria for register 0 coming in when not requested, and lets
 us
> (OHCI hardware) not care about bus resets or outstanding register requests.
>
> Joe
>
From:	Josh Collier - SMCC Hardware [Josh.Collier@East.Sun.COM]
Sent:	Wednesday, August 13, 1997 3:23 PM
To:	1394ohci-l@austin.ibm.com
Cc:	Josh.Collier@East.Sun.COM
Subject:	Problem with EVT_DATA_READ

Possible Problems With evt_data_read

OHCI 94 specifies that upon a host bus read error, packet data is no
longer place in the fifo. Will the link detect this as a fifo underrun?

      Table 1: Possible Situations
+-------------------------------------------------------------------------+
| Case | Host Bus   | Link     | Ack from     | Status        | Retry ?   |
|      | Read Error | Underrun | Bus          |               |           |
+-------------------------------------------------------------------------+
|   0  |    No      |    No    | Don't Care   | Ack from Bus  | if needed |
|   1  |    No      |    Yes   | Don't Care   | evt_underrun  | No        |
|   2  |    Yes     |    Yes   | Don't Care   | evt_data_read | No        | 
|   3  |    Yes     |    No    | ack_data_err | evt_data_read | No        |
|   4  |    Yes     |    No    | not ack_data | Ack from Bus  | No        |
+-------------------------------------------------------------------------+

Case 0 : Normal Bus operation. No Problems here.

Case 1 : Link underrun occured.
         Causes:
                 - Software: Bad data length, bad req_count, ect..
                 - Host Bus latency issue.
         Standard status is evt_underrun, with no retry.
         
Case 2 : Two things can happen here. One, the link begins to transmit a
         packet and encounters a fifo underrun before the host dma is
         finished creating the packet. However, the host dma receives a
         host bus error on the remaining data, the link has already
         finished sending the underrun packet and acks to the host
         evt_underrun. In this case it is sensible to apply case 1 rules
         here and pass back the evt_underrun, since the underrun occured
         first. The second situation is that a host bus error occurs and
         the link sends the packet but detects that it has underrun. The
         link acks to the host evt_underrun, and the host, (I think)
         should respond with evt_data_read.
         
Case 3 : This is where it gets sketchy. A Host bus error occured but the
         link did not detect a fifo underrun. The link responds back with
         the ack code received from the bus. If the ack is ack_data_err
         then the packet status gets set to evt_data_read, otherwise the
         condition becomes Case 4 and the packet status becomes the
         received ack.

The problem arises when a Host Bus Read Error occurs and the link does
not detect an underrun.

Question: Do most links check for fifo underrun?

Question: Do most links not append CRC upon underrun?

Question: If you know the packet is going to underrun, do you need to
          observe the ack from the other node?

Question: Is it possible for the link to not detect an underrun of a
          packet in which a host bus read error occurred?
  - If the aligner contains data prior to a host bus read error. Should
    that data be thrown away in order to force an underrun in the link.
    I.E. the dma engine fetches 3 bytes which were successful, and the
    attempts to fetch one last byte which the error occurs in. The three
    bytes which are in the aligner, if written in to the fifo with zero
    padding, would no cause an underrun. The link can not count bytes
    due to the fact that it is not aware of the padding, and hence only
    can count by quadlets.

Question: If the link reports back an underrun before a host bus error
          occurs, this should be construed as an evt_underrun_err,
          because the packet had already been sent, and dues to host bus
          latency the remaining data was not able to be transmitted.
          However, a host bus error occurred during the dma transfer
          of the remaining bytes. What is the correct ack?
          evt_underrun_err or evt_data_read?

________________________________________________________________________

 Josh Collier					Tel: 508-442-0471
 Member of Technical Staff			Fax: 508-442-1575
 Workgroup Server Hardware Engineering
 Sun Microsystems Computer Corporation
 Chelmsford, Massachusetts			
________________________________________________________________________

From:	Young, Mark [MARKYOUNG@TX.SLR.COM]
Sent:	Friday, August 15, 1997 2:56 PM
To:	'1394 OHCI Reflector'
Subject:	Bus Reset Packet & rcvPhyPkt

The 0.94 spec does not say one way or the other whether
LinkControl.rcvPhyPkt  controls the reception of the Bus Reset pkt.
Since it is a PHY pkt, I would assume so, but assumtions get me into
trouble!

Does clearing LinkControl.rcvPhyPkt prevent Bus Reset pkts from being
RCV'ed?  I refer to Table 5-15, para 8.4.2.3 and para 8.5.


Regards,
 Mark Young
 Solectron, Texas
 Phone:  512-425-4253
 Email:  MarkYoung@tx.slr.com
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Friday, August 15, 1997 4:00 PM
To:	1394ohci-l@austin.ibm.com
Cc:	klashman@east.sun.com
Subject:	Re: Bus Reset Packet & rcvPhyPkt

Mark,

My *opinion* follows ...

I don't believe LinkControl.rcvPhyPkt should ever apply to the synthesized bus 
reset packet inserted into the ARDMA queue by the link.  My halfhearted (it is 
Friday after all) reasoning includes:

- the bus reset packet or "token" is needed by software to manage stale 
source_ID's which occur after a bus reset.  Even if software wants to filter 
other "PHY" packets, it must still always see the reset token.

- In Table 5-15, you'll note that LinkControl.rcv.PhyPkt does not include 
self-id packets.  Since a bus reset usually accompanies a self-id sequence, I 
don't think this bit was intended to control resets but not self-id's.

- Bus resets are not actually packets on the wire.  Clause 8.5 defines "PHY 
packets" as any packet which is 2 quadlets long and fails a CRC check.  Bus 
resets clearly don't fall into this category.

To clear up any spec ambiguity, we could request that the following edit be 
adopted:

Table 5-15:

Change last sentence of rcvPhyPkt description to read "This does not control 
either the receipt of self-identification packets received during the self-ID 
phase of bus initialization or the queuing of synthesized bus reset packets in 
the AR DMA Request Context buffer.  This does control receipt of any 
self-identification packets received outside of the self_ID phase of bus 
initialization.

Regards,
Jerry Hauck
Intel Corp
(408) 765-5528
jerry_hauck@ccm.sc.intel.com

______________________________ Reply Separator _________________________________
Subject: Bus Reset Packet & rcvPhyPkt
Author:  leew@austin.ibm.com at SMTPGATE
Date:    8/15/97 4:56 PM


The 0.94 spec does not say one way or the other whether 
LinkControl.rcvPhyPkt  controls the reception of the Bus Reset pkt. 
Since it is a PHY pkt, I would assume so, but assumtions get me into 
trouble!

Does clearing LinkControl.rcvPhyPkt prevent Bus Reset pkts from being 
RCV'ed?  I refer to Table 5-15, para 8.4.2.3 and para 8.5.


Regards,
 Mark Young
 Solectron, Texas
 Phone:  512-425-4253
 Email:  MarkYoung@tx.slr.com
From:	Wooten,David [David.Wooten@compaq.com]
Sent:	Monday, August 18, 1997 7:40 AM
To:	'1394ohci-l@austin.ibm.com'
Subject:	RE: Bus Reset Packet & rcvPhyPkt

My opinion matches Jerry's.

In the opinion of the editor, how many opinions does it take to make a 
decision (not counting the opinion of the editor which is singularly 
decisive)?

David Wooten

-----Original Message-----
From:	Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com]
Sent:	Friday, August 15, 1997 6:00 PM
To:	1394ohci-l@austin.ibm.com
Cc:	klashman@east.sun.com
Subject:	Re: Bus Reset Packet & rcvPhyPkt

Mark,

My *opinion* follows ...

I don't believe LinkControl.rcvPhyPkt should ever apply to the 
synthesized bus
reset packet inserted into the ARDMA queue by the link.  My 
halfhearted (it is
Friday after all) reasoning includes:

- the bus reset packet or "token" is needed by software to manage 
stale
source_ID's which occur after a bus reset.  Even if software wants to 
filter
other "PHY" packets, it must still always see the reset token.

- In Table 5-15, you'll note that LinkControl.rcv.PhyPkt does not 
include
self-id packets.  Since a bus reset usually accompanies a self-id 
sequence, I
don't think this bit was intended to control resets but not 
self-id's.

- Bus resets are not actually packets on the wire.  Clause 8.5 defines 
"PHY
packets" as any packet which is 2 quadlets long and fails a CRC check. 
 Bus
resets clearly don't fall into this category.

To clear up any spec ambiguity, we could request that the following 
edit be
adopted:

Table 5-15:

Change last sentence of rcvPhyPkt description to read "This does not 
control
either the receipt of self-identification packets received during the 
self-ID
phase of bus initialization or the queuing of synthesized bus reset 
packets in
the AR DMA Request Context buffer.  This does control receipt of any
self-identification packets received outside of the self_ID phase of 
bus
initialization.

Regards,
Jerry Hauck
Intel Corp
(408) 765-5528
jerry_hauck@ccm.sc.intel.com

______________________________ Reply Separator 
_________________________________
Subject: Bus Reset Packet & rcvPhyPkt
Author:  leew@austin.ibm.com at SMTPGATE
Date:    8/15/97 4:56 PM


The 0.94 spec does not say one way or the other whether
LinkControl.rcvPhyPkt  controls the reception of the Bus Reset pkt.
Since it is a PHY pkt, I would assume so, but assumtions get me into
trouble!

Does clearing LinkControl.rcvPhyPkt prevent Bus Reset pkts from being 
RCV'ed?  I refer to Table 5-15, para 8.4.2.3 and para 8.5.


Regards,
 Mark Young
 Solectron, Texas
 Phone:  512-425-4253
 Email:  MarkYoung@tx.slr.com
From:	klashman@meow.East.Sun.COM
Sent:	Monday, August 18, 1997 10:53 AM
To:	1394ohci-l@austin.ibm.com
Subject:	RE: Bus Reset Packet & rcvPhyPkt

Yes, I agree as well and have made the change.

How many opinions does it take?  It depends on whose opinions they
are.  For example, opinions from people who post jokes which offend
or annoy the editor, well, those opinions get diluted since the
sources have discredited themselves.  :-)

Diana

----- Begin Included Message -----

From David.Wooten@COMPAQ.com Mon Aug 18 12:02:29 1997
From: "Wooten,David" <David.Wooten@COMPAQ.com>
To: "'1394ohci-l@austin.ibm.com'" <1394ohci-l@austin.ibm.com>
Subject: RE: Bus Reset Packet & rcvPhyPkt

My opinion matches Jerry's.

In the opinion of the editor, how many opinions does it take to make a 
decision (not counting the opinion of the editor which is singularly 
decisive)?

David Wooten

-----Original Message-----
From:	Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com]
Sent:	Friday, August 15, 1997 6:00 PM
To:	1394ohci-l@austin.ibm.com
Cc:	klashman@east.sun.com
Subject:	Re: Bus Reset Packet & rcvPhyPkt

Mark,

My *opinion* follows ...

I don't believe LinkControl.rcvPhyPkt should ever apply to the 
synthesized bus
reset packet inserted into the ARDMA queue by the link.  My 
halfhearted (it is
Friday after all) reasoning includes:

- the bus reset packet or "token" is needed by software to manage 
stale
source_ID's which occur after a bus reset.  Even if software wants to 
filter
other "PHY" packets, it must still always see the reset token.

- In Table 5-15, you'll note that LinkControl.rcv.PhyPkt does not 
include
self-id packets.  Since a bus reset usually accompanies a self-id 
sequence, I
don't think this bit was intended to control resets but not 
self-id's.

- Bus resets are not actually packets on the wire.  Clause 8.5 defines 
"PHY
packets" as any packet which is 2 quadlets long and fails a CRC check. 
 Bus
resets clearly don't fall into this category.

To clear up any spec ambiguity, we could request that the following 
edit be
adopted:

Table 5-15:

Change last sentence of rcvPhyPkt description to read "This does not 
control
either the receipt of self-identification packets received during the 
self-ID
phase of bus initialization or the queuing of synthesized bus reset 
packets in
the AR DMA Request Context buffer.  This does control receipt of any
self-identification packets received outside of the self_ID phase of 
bus
initialization.

Regards,
Jerry Hauck
Intel Corp
(408) 765-5528
jerry_hauck@ccm.sc.intel.com

______________________________ Reply Separator 
_________________________________
Subject: Bus Reset Packet & rcvPhyPkt
Author:  leew@austin.ibm.com at SMTPGATE
Date:    8/15/97 4:56 PM


The 0.94 spec does not say one way or the other whether
LinkControl.rcvPhyPkt  controls the reception of the Bus Reset pkt.
Since it is a PHY pkt, I would assume so, but assumtions get me into
trouble!

Does clearing LinkControl.rcvPhyPkt prevent Bus Reset pkts from being 
RCV'ed?  I refer to Table 5-15, para 8.4.2.3 and para 8.5.


Regards,
 Mark Young
 Solectron, Texas
 Phone:  512-425-4253
 Email:  MarkYoung@tx.slr.com



----- End Included Message -----

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Member of Technical Staff                                |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From:	Jaideep Bhatia [jaideep@wipinfo.soft.net]
Sent:	Monday, August 18, 1997 10:43 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Bus Management CSR Registers


	The bus management csr registers are accessible either from the 
host system or from the 1394 bus. Table 5-5 page 39 ohci draft 0.94 says 
csrData to be rwu and csrCompare to be rw.

	If csrCompare's attributes are correct then it means it cannot be 
written by the host controller.(as no u status is there.) For those 
requests those are coming from the 1394 bus should go to the host system 
(software). Or they will come through the host bus back into the host 
controller.

	Which one of the above options is correct, or am I missing 
something. 

Regards,

Jaideep Bhatia
Senior Engineer, R&D Hardware
Wipro Infotech Limited
88, M G Road
Bangalore 560001
India

91-80- 5588422,5588667	Ext:553
jaideep@wipinfo.soft.net
From:	Jaideep Bhatia [jaideep@wipinfo.soft.net]
Sent:	Monday, August 18, 1997 10:57 PM
To:	1394ohci-l@austin.ibm.com
Subject:	IR with header/trailer packet-per-buffer

	On page 123 ohci draft-0.94 for IR with header/trailer 
packet-per-buffer mode, the trailer is shown as first quadlet. And first 
two bytes are invalid. This may be consciously put like that. Just out of 
curiosity, any specific reason why it is done like that and why 
xferStatus is not important in this context.

	Second confusion is related with the figure 10-11 on the same 
page. It says "If headers are in a seperate buffer from data, then the 
data buffer may be quadlet aligned."

	But there dosen't seem to be any buffer for storing the headers 
only. Any comments !!

Regards,

Jaideep Bhatia
Senior Engineer, R&D Hardware
Wipro Infotech Limited
88, M G Road
Bangalore 560001
India

91-80- 5588422,5588667	Ext:553
jaideep@wipinfo.soft.net
From:	joec@lsi.sel.sony.com
Sent:	Tuesday, August 19, 1997 10:34 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: R with header/trailer packet-per-buffer



For your second confusion, I have the same one before.
BTW, you have typo on quadlet aligned, it should be byte aligned.

For packet-per-buffer mode, you can have mutiple IM and one IL
to be a big buffer. I guess the "separate buffer" mean the different small
buffers from IM and IL which create the big buffer for the whole packet.

That means if first IM is 2 quadlet buffer, then the second IM
buffer could be byte-aligned.

********************************************
* Joe (Chen-Chi Chou), SONY Corp.
* Tel: (408)955-4555, Fax: (408)955-5180
********************************************


----- Begin Included Message -----

>From leew@austin.ibm.com Mon Aug 18 22:40:42 1997
Date: Tue, 19 Aug 1997 10:57:19 +0500 (GMT+0500)
From: Jaideep Bhatia <jaideep@wipinfo.soft.net>
To: 1394ohci-l@austin.ibm.com
Subject: IR with header/trailer packet-per-buffer
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 752
X-Lines: 25

	On page 123 ohci draft-0.94 for IR with header/trailer 
packet-per-buffer mode, the trailer is shown as first quadlet. And first 
two bytes are invalid. This may be consciously put like that. Just out of 
curiosity, any specific reason why it is done like that and why 
xferStatus is not important in this context.

	Second confusion is related with the figure 10-11 on the same 
page. It says "If headers are in a seperate buffer from data, then the 
data buffer may be quadlet aligned."

	But there dosen't seem to be any buffer for storing the headers 
only. Any comments !!

Regards,

Jaideep Bhatia
Senior Engineer, R&D Hardware
Wipro Infotech Limited
88, M G Road
Bangalore 560001
India

91-80- 5588422,5588667	Ext:553
jaideep@wipinfo.soft.net



----- End Included Message -----




----- End Included Message -----
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Wednesday, August 20, 1997 11:34 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Bus Management CSR Registers

Jaideep,

The spec is correct.  While the bus management csr registers 
(BUS_MANAGER_ID, BW_AVAILABLE, & CH_AVAILABLEs) _are_ accessible from 
both the host and 1394 side, the OHCI specfic registers used to access 
these CSR's from the host side are *not* accessible from 1394.  In 
other words, a 1394 device can not (nor does it need to) operate on 
csrData, csrCompare, or csrControl.  Instead, read or lock requests 
from 1394 for the management registers operate directly on the CSR 
registers implemented in hardware.

csrData, csrCompare, and csrControl are only needed so that host 
software can perform lock operations on the hardware CSR registers.  
csrData is "rwu" and includes the "u" so that the results of a 
host-initiated lock can be returned.  csrCompare is only written by 
software ... OHCI hardware never needs to update its value.

The differences may be subtle, but the spec is correct.

Regards,
Jerry Hauck
Intel Corp.
(408) 765-5528
jerry_hauck@ccm.sc.intel.com

______________________________ Reply Separator _________________________________
Subject: Bus Management CSR Registers
Author:  leew@austin.ibm.com at SMTPGATE
Date:    8/19/97 10:43 AM


     The bus management csr registers are accessible either from the
host system or from the 1394 bus. Table 5-5 page 39 ohci draft 0.94 says 
csrData to be rwu and csrCompare to be rw.

     If csrCompare's attributes are correct then it means it cannot be
written by the host controller.(as no u status is there.) For those 
requests those are coming from the 1394 bus should go to the host system 
(software). Or they will come through the host bus back into the host 
controller.

     Which one of the above options is correct, or am I missing
something.

Regards,

Jaideep Bhatia
Senior Engineer, R&D Hardware
Wipro Infotech Limited
88, M G Road
Bangalore 560001
India

91-80- 5588422,5588667     Ext:553
jaideep@wipinfo.soft.net
From:	Lindeman@corp.adaptec.com
Sent:	Friday, August 22, 1997 9:34 AM
To:	1394ohci-l@austin.ibm.com
Subject:	unsubscribe

Form: Memo
Text: (1 line follows)
unsubscribe
Use Proportional Font: true
Attachment Count: 0
--$----Novell--Attachment----$

X-NVL-Content-Type: UNKNOWN
X-NVL-Content-Typename: UNKNOWN
X-NVL-Content-Charset: X-IBM-437
X-NVL-Content-Filename: ATTRIBS.BND
X-NVL-Content-Transfer-Encoding: X-UUENCODE


--$----Novell--Attachment----$--
From:	alpham@unix.advansys.com
Sent:	Friday, August 22, 1997 6:22 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Question on IR DMA ContextMatch register

Hi,

Possible discrepancy:

On page 118 of OHCI spec v0.94, table 10-4 describes cycleMatch as
a 15-bit value, but Figure 10-6 shows cycleMatch bit positions from
12 thru 25 which is only 14 bits.  

Should cycleMatch be from bits 12 thru 26 in figure 10-6?

-- AL Pham
-- AdvanSys
From:	klashman@meow.East.Sun.COM
Sent:	Saturday, August 23, 1997 10:27 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Question on IR DMA ContextMatch register

Yes, bit 26 should not be shaded.  This will be fixed in the
next version.

Diana

>From alpham@unix.advansys.com Fri Aug 22 21:29:05 1997
>
>Hi,
>
>Possible discrepancy:
>
>On page 118 of OHCI spec v0.94, table 10-4 describes cycleMatch as
>a 15-bit value, but Figure 10-6 shows cycleMatch bit positions from
>12 thru 25 which is only 14 bits.  
>
>Should cycleMatch be from bits 12 thru 26 in figure 10-6?
>
>-- AL Pham
>-- AdvanSys
>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Member of Technical Staff                                |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From:	Jaideep Bhatia [jaideep@wipinfo.soft.net]
Sent:	Friday, August 22, 1997 11:54 PM
To:	1394ohci-l@austin.ibm.com
Subject:	Bus reset values of Bus Management regs

	Clause 5.5.1 page 38 ohci draft 0.94 shows the bus reset values 
for all the 4 CSR registers. Clause 9.5.2 page 108 says " Bus reset does 
not affect isochronous transmit." And it is evident from figure 9-9 page 
107 also.

	If the registers change there values at bus reset, the 
isochronous transmission cannot continue because all of the channels 
become unallocated and whole bandwidth is available. If old nodes continue 
the transmission and more new nodes join the isochronous transmission, 
the problems of transmission on duplicate channel and excessive bandwidth 
utilization may happen on the bus.

	The correct thing will be to mark these registers unaffected by 
the bus reset ( and may be soft reset also). And correct the table C-1 on 
page 145 too. 

Regards,

Jaideep Bhatia
Senior Engineer, R&D Hardware
Wipro Infotech Limited
88, M G Road
Bangalore 560001
India

91-80- 5588422,5588667	Ext:553
jaideep@wipinfo.soft.net
From:	klashman@meow.East.Sun.COM
Sent:	Saturday, August 23, 1997 11:34 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Re: Bus reset values of Bus Management regs

Actually the specified behavior is correct.  Although isochronous
data transfer continues following a bus reset, the resource
owner(s) - those who had allocated the bandwidth and channel(s) in the
first place - are responsible for reallocating them after the bus reset.

Why re-allocate rather than leaving the registers untouched across
a bus reset?  Well, as a result of the bus reset the isochronous
resource manager could now be a different node.  Or perhaps two
busses were merged which each could have been using the same channel
numbers prior to the bus reset.

Typically the bandwidth and channel(s) can be reallocated as before
and the isochronous traffic continues uninterrupted.  This of course
is the desired behavior.  However, there are cases such as merging
two busses where this may not be possible.  In that case the
appropriate isochronous talkers and listeners must stop and may
be restarted when new resources are allocated.

For nodes using the Plug Control registers, the realloc of resources
and the notification of the talkers and listeners that were active
prior to the bus reset must be done within one second following
the bus reset.

For more information on this, see 1394-1995 section 8.4.2.4 (pg 230),
and P1394A section 8.2.1 Transition P3:P1.

Diana

>From jaideep@wipinfo.soft.net Sat Aug 23 02:32:08 1997
>
>	Clause 5.5.1 page 38 ohci draft 0.94 shows the bus reset values 
>for all the 4 CSR registers. Clause 9.5.2 page 108 says " Bus reset does 
>not affect isochronous transmit." And it is evident from figure 9-9 page 
>107 also.
>
>	If the registers change there values at bus reset, the 
>isochronous transmission cannot continue because all of the channels 
>become unallocated and whole bandwidth is available. If old nodes continue 
>the transmission and more new nodes join the isochronous transmission, 
>the problems of transmission on duplicate channel and excessive bandwidth 
>utilization may happen on the bus.
>
>	The correct thing will be to mark these registers unaffected by 
>the bus reset ( and may be soft reset also). And correct the table C-1 on 
>page 145 too. 
>
>Regards,
>
>Jaideep Bhatia
>Senior Engineer, R&D Hardware
>Wipro Infotech Limited
>88, M G Road
>Bangalore 560001
>India
>
>91-80- 5588422,5588667	Ext:553
>jaideep@wipinfo.soft.net


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: klashman@east.sun.com |
| Member of Technical Staff                                |
| Sun Microsystems            phone: (508) 442-0575        |
| 4 Omni Way,  MS CHL04-201     fax: (508) 250-5060        |
| Chelmsford, MA 01824                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
From:	cylin@sis.com.tw
Sent:	Monday, August 25, 1997 12:29 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Cycle master cycle match problem

Hi, all:

According to OHCI0.94, a write to the cycleTimer register in the
cycle master will not cause a cycleInconsistent interrupt. However,
this will cause the host side timer to become inconsistent with the
link side timer- the difference becomes much more than 2. Since 
software only sees the link side timer, but hardware uses host side 
timer to perform cycle match operation, packet will not be transmitted
at the expected cycle. I suggest software stops the not-yet active 
(run=1, active=0) context(s) before it writes the (link side) 
cycle timer, because it is known that overwriting the cycle timer
will effect the cycle match operation.

Best regards,

C.Y.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chien-Yuh Lin
Design Engineer
Basic Technology Group
Silicon Intergrated Systems Corp.
Tel: 886-3-5774922 x 4326
Fax: 886-3-5778774
Email: cylin@sis.com.tw
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From:	Siby Abraham [siby@wipinfo.soft.net]
Sent:	Monday, August 25, 1997 6:20 AM
To:	1394ohci-l@austin.ibm.com; aarathy@wipinfo.soft.net; valavi@wipinfo.soft.net; jaideep@wipinfo.soft.net; raomn@wipinfo.soft.net; siby@wipinfo.soft.net; simonj@wipinfo.soft.net; sukalyan@wipinfo.soft.net; tapasd@wipinfo.soft.net
Subject:	cycleMatchEnable Clearing and CycleInconsistent

Hi All,

When do we clear the CycleMatchEnable bit ie.
when the counter maintained by Dma matches the
cycleMatch or when the link side counter matches
cycleMatch ?

These 2 counters will differ as much by the value
of ahead_counter.

For a non-zero value of ahead counter, dma will see
a match and load the packet corresponding to the
context ahead of the actual link side match. Now
if a cycleInconsistent comes before the packet is
transmitted from link, what is the expected behavior
from link?

.94 draft of ohci says , all cyclematch Enabled contexts
should stop on a cycleInconsistent interrupt. If this
is the case, one would assume that we can't transmit
the packet. Further cycleMatchEnable bit may have to
remain set in context control reg . This would mean
we don't clear the cyclematchEnable until link side
counter gets a match (even though the packet is loaded
in the fifo).

On the other hand, if cyclematchEnable is cleared when
dma has got a match, the context will remain active
even after cycleInconsistent (since there won't be
any indication of it having been enabled.)

Which is the expected behavior? Thanks in advance for
a clarification.

Siby
From:	Allan Flippin [allan@issiusa.com]
Sent:	Monday, August 25, 1997 2:50 PM
To:	1394ohci-l@austin.ibm.com; jherbst@issiusa.com; msodos@issiusa.com
Subject:	Some questions about Asynchronous Streams

     I've seen the references to Asynchronous Streams in both the 1394A
draft 0.9x, and the OHCI draft 0.94.  I think I have the concepts down
fairly well, but have a few questions about handling Asynchronous
Streams in an OHCI-compatible controller design.

1)  Is the Asynchronous Stream packet considered a "request" or
"response"?  For instance, when software sets up context descriptors to
define an Asynchronous Stream for transmit, are these descriptors placed
in the AT Request or AT Response context?  I realize this question
doesn't really matter to the controller, as we can transmit the packets
either way.  However, the question matters more in connection with
receiving Asynchronous Stream packets, leading to my questions which
follow.

2)  There is no mention of Asynchronous Stream packets in OHCI section 8
(AR DMA).  I assume that since we have provision for sending them, we
also need to receive them.  Is this right?

3)  If the answer to #2 is "yes", then I see some problems.  How can we
know which Asynchronous Stream packets are addressed to this node?  For
IR packets, this is no problem because we have IR context match
registers to let us know which ISO packets should be received and where
to put them.  But there is no corresponding information for Asynchronous
Stream packets.
     Presently, the only thing I can think of is to declare any incoming
packet with tcode = 0Ah as an Aysnchronous Stream packet if it doesn't
match any IR context (including the multi-channel context, if enabled).
This could be bad, because we'd end up gobbling up a lot of memory space
and system bus bandwidth for packets which weren't intended for this
node anyway.

4)  How does this fit in with "loose isochronous"?  For example, since
Asynchronous Stream packets must be transmitted during the asynchronous
time period, and ISO packets should be transmitted during the ISO time
period, I could declare that any tcode = 0Ah packet received during the
asynchronous time period has to be an incoming Asynchronous Stream.
     This seems like a bad idea though, since due to bus resets and
garbled up cycle start packets, we might not always know the exact
boundaries of ISO versus asynchronous time periods.  My inclination is
to simply match the incoming tcode = 0Ah packets based on channel
number.  Does this sound right?  I'm still left with the question of how
the the OHCI-compatible controller knows which channel numbers to listen
to for incoming Asynchronous Streams.

5)   Back to the first question, should incoming Asynchronous Stream
packets be directed to the AR request or AR response queue?

     My personal bias is to call an Asynchronous Stream packet a
"request" in either direction.  A set of "ARMultiChanMask" registers
could be set up in the same format as the present "IRMultiChanMask"
registers to specify which channels should be monitored for incoming
Asynchronous Stream packets in the AR request context.

     Thanks for you help.

     Allan Flippin

From:	Eric W. Anderson [ewa@apple.com]
Sent:	Monday, August 25, 1997 4:49 PM
To:	1394ohci-l@austin.ibm.com
Cc:	munroe@apple.com
Subject:	Subscribe

Please add Kevin Munroe, <munroe@apple.com>, to this list.

--------------------------------------
Eric Anderson            ewa@apple.com
Apple Computer, Inc.     (408)974-8187
--------------------------------------


From:	John Nels Fuller
Sent:	Monday, August 25, 1997 6:12 PM
To:	'Allan Flippin'; 1394ohci-l@austin.ibm.com; jherbst@issiusa.com; msodos@issiusa.com
Subject:	RE: Some questions about Asynchronous Streams

See below:

> -----Original Message-----
> From:	Allan Flippin [SMTP:allan@issiusa.com]
> Sent:	Monday, August 25, 1997 2:50 PM
> To:	1394ohci-l@austin.ibm.com; jherbst@issiusa.com;
> msodos@issiusa.com
> Subject:	Some questions about Asynchronous Streams
> 
>      I've seen the references to Asynchronous Streams in both the
> 1394A
> draft 0.9x, and the OHCI draft 0.94.  I think I have the concepts down
> fairly well, but have a few questions about handling Asynchronous
> Streams in an OHCI-compatible controller design.
> 
> 1)  Is the Asynchronous Stream packet considered a "request" or
> "response"?  For instance, when software sets up context descriptors
> to
> define an Asynchronous Stream for transmit, are these descriptors
> placed
> in the AT Request or AT Response context?  I realize this question
> doesn't really matter to the controller, as we can transmit the
> packets
> either way.  However, the question matters more in connection with
> receiving Asynchronous Stream packets, leading to my questions which
> follow.
	[John Nels Fuller]  Asynchronous Stream packets are considered
requests and should be put into the AT Request context.

> 2)  There is no mention of Asynchronous Stream packets in OHCI section
> 8
> (AR DMA).  I assume that since we have provision for sending them, we
> also need to receive them.  Is this right?
	[John Nels Fuller]  No, they look like "loose" isochronous
packets on receive and are handled by IR DMA (filtered by channel
number, etc.).

> 3)  If the answer to #2 is "yes", then I see some problems.  How can
> we
> know which Asynchronous Stream packets are addressed to this node?
> For
> IR packets, this is no problem because we have IR context match
> registers to let us know which ISO packets should be received and
> where
> to put them.  But there is no corresponding information for
> Asynchronous
> Stream packets.
>      Presently, the only thing I can think of is to declare any
> incoming
> packet with tcode = 0Ah as an Aysnchronous Stream packet if it doesn't
> match any IR context (including the multi-channel context, if
> enabled).
> This could be bad, because we'd end up gobbling up a lot of memory
> space
> and system bus bandwidth for packets which weren't intended for this
> node anyway.
> 
> 4)  How does this fit in with "loose isochronous"?  For example, since
> Asynchronous Stream packets must be transmitted during the
> asynchronous
> time period, and ISO packets should be transmitted during the ISO time
> period, I could declare that any tcode = 0Ah packet received during
> the
> asynchronous time period has to be an incoming Asynchronous Stream.
>      This seems like a bad idea though, since due to bus resets and
> garbled up cycle start packets, we might not always know the exact
> boundaries of ISO versus asynchronous time periods.  My inclination is
> to simply match the incoming tcode = 0Ah packets based on channel
> number.  Does this sound right?  I'm still left with the question of
> how
> the the OHCI-compatible controller knows which channel numbers to
> listen
> to for incoming Asynchronous Streams.
	[John Nels Fuller]  On receive the controller doesn't make a
distinction between Isochronous Streams and Asynchronous Streams.
"Loose isochronous" simply means that we will receive a tcode 0Ah packet
in either ISO or ASYNC period.  If received during the ASYNC period it
might be an ISO packet for which we saw a mangled cycle start or it
might be an async stream packet.

> 5)   Back to the first question, should incoming Asynchronous Stream
> packets be directed to the AR request or AR response queue?
> 
>      My personal bias is to call an Asynchronous Stream packet a
> "request" in either direction.  A set of "ARMultiChanMask" registers
> could be set up in the same format as the present "IRMultiChanMask"
> registers to specify which channels should be monitored for incoming
> Asynchronous Stream packets in the AR request context.
	[John Nels Fuller]  As I said before, they are directed at IR
not AR.

>      Thanks for you help.
> 
>      Allan Flippin
> 
From:	Allan Flippin [allan@issiusa.com]
Sent:	Monday, August 25, 1997 6:33 PM
To:	John Nels Fuller
Cc:	1394ohci-l@austin.ibm.com; jherbst@issiusa.com; msodos@issiusa.com
Subject:	Re: Some questions about Asynchronous Streams

John Nels Fuller wrote:

>      On receive the controller doesn't make a distinction between
> Isochronous Streams and Asynchronous Streams.  "Loose isochronous"
> simply means that we will receive a tcode 0Ah packet in either ISO or
> ASYNC period.  If received during the ASYNC period it might be an ISO
> packet for which we saw a mangled cycle start or it might be an async
> stream packet.
>

     Thanks, that clears up everything!  So basically I can treat all
incoming tcode 0Ah packets as if they are ISO.

Allan Flippin
ISSI

From:	Santhosh Kumar M [mskumar@wipinfo.soft.net]
Sent:	Tuesday, August 26, 1997 9:55 PM
To:	'ReflectorOHCI'
Subject:	phy and PhyRegRcvd Interrupt 

Hi all :  
     From Section 6.2.1 ( page 54) of OHCI 0.94 draft spec. the setting of Interrupt Event bits
     for phy ( bit 19 Interrupt Event Reg) and phyRegRcvd ( bit 26 of Interrupt Event Reg)
     is not clear.

     1. As per the spec the phy interrupt event is set when "PHY requests an interrupt through 
         a status transfer". So does this interrupt get Set for register status transfers also?

     2. If the answer is "yes" then when does the phyregRcvd interrupt event set ? 
         Again does phyRegRcvd interrupt get set for requests of register read made thro' PHY 
         control register only or Does it get set for all register transfers independent of PHY control
         register requests for eg. register 0 transfers. 

      Pls clarify the above.
Regards
Santhosh Kumar M
mskumar@wipinfo.soft.net
From:	Josh Collier - SMCC Hardware [jcollier@simplicity.East.Sun.COM]
Sent:	Wednesday, August 27, 1997 5:42 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Questions about EVT_DATA_READ

Questions are at the bottom, thanks.

Possible Problems With evt_data_read

OHCI 94 specifies that upon a host bus read error, packet data is no
longer place in the fifo. Will the link detect this as a fifo underrun?

      Table 1: Possible Situations
+-------------------------------------------------------------------------+
| Case | Host Bus   | Link     | Ack from     | Status        | Retry ?   |
|      | Read Error | Underrun | Bus          |               |           |
+-------------------------------------------------------------------------+
|   0  |    No      |    No    | Don't Care   | Ack from Bus  | if needed |
|   1  |    No      |    Yes   | Don't Care   | evt_underrun  | No        |
|   2  |    Yes     |    Yes   | Don't Care   | evt_data_read | No        | 
|   3  |    Yes     |    No    | ack_data_err | evt_data_read | No        |
|   4  |    Yes     |    No    | not ack_data | Ack from Bus  | No        |
+-------------------------------------------------------------------------+

Case 0 : Normal Bus operation. No Problems here.

Case 1 : Link underrun occured.
         Causes:
                 - Software: Bad data length, bad req_count, ect..
                 - Host Bus latency issue.
         Standard status is evt_underrun, with no retry.
         
Case 2 : Two things can happen here. One, the link begins to transmit a
         packet and encounters a fifo underrun before the host dma is
         finished creating the packet. However, the host dma receives a
         host bus error on the remaining data, the link has already
         finished sending the underrun packet and acks to the host
         evt_underrun. In this case it is sensible to apply case 1 rules
         here and pass back the evt_underrun, since the underrun occured
         first. The second situation is that a host bus error occurs and
         the link sends the packet but detects that it has underrun. The
         link acks to the host evt_underrun, and the host, (I think)
         should respond with evt_data_read.
         
Case 3 : This is where it gets sketchy. A Host bus error occured but the
         link did not detect a fifo underrun. The link responds back with
         the ack code received from the bus. If the ack is ack_data_err
         then the packet status gets set to evt_data_read, otherwise the
         condition becomes Case 4 and the packet status becomes the
         received ack.

The problem arises when a Host Bus Read Error occurs and the link does
not detect an underrun.

Question: Do most links check for fifo underrun?

Question: Do most links not append CRC upon underrun?

Question: If you know the packet is going to underrun, do you need to
          observe the ack from the other node?

Question: Is it possible for the link to not detect an underrun of a
          packet in which a host bus read error occurred?
  - If the aligner contains data prior to a host bus read error. Should
    that data be thrown away in order to force an underrun in the link.
    I.E. the dma engine fetches 3 bytes which were successful, and the
    attempts to fetch one last byte which the error occurs in. The three
    bytes which are in the aligner, if written in to the fifo with zero
    padding, would no cause an underrun. The link can not count bytes
    due to the fact that it is not aware of the padding, and hence only
    can count by quadlets.

Question: If the link reports back an underrun before a host bus error
          occurs, this should be construed as an evt_underrun_err,
          because the packet had already been sent, and due to host bus
          latency the remaining data was not able to be transmitted.
          However, a host bus error occurred during the dma transfer
          of the remaining bytes. What is the correct ack?
          evt_underrun_err or evt_data_read?

________________________________________________________________________

 Josh Collier					Tel: 508-442-0471
 Member of Technical Staff			Fax: 508-442-1575
 Workgroup Server Hardware Engineering
 Sun Microsystems Computer Corporation
 Chelmsford, Massachusetts			
________________________________________________________________________
From:	Jaideep Bhatia [jaideep@wipinfo.soft.net]
Sent:	Thursday, August 28, 1997 6:07 AM
To:	1394ohci-l@austin.ibm.com
Subject:	Physical Upper bound accesses


	If the physical upper bound register is implemented then the 
physical req/response unit has to handle the address range from 
48'h0000_0000_0000 to {PhysicalUpperBound, 16h0000}-1. Where the max value 
of the PhysicalUpperBound is ffff_0000 as per clause 5.14 page 52 ohci 
draft 0.94.
	Page 129 part a of clause 12 says "If the higher order 16-bits of 
the offset address id 16'h0000 and PhysicalUpperBound is not implemented, 
then the lower 32-bits of the offset address are used as the memory 
address for the block or quadlet transaction."

	It dosen't say what address to take for memory access if the 
PhysicalUpperBound register is implemented. So the following cases may arise.

1. uppper 16 bits are 16'h0000
	a direct memory access can be performed with lower 32 bit 
	address. Should it be done like this ???

2. upper 16 bits are not 16'h0000
        a memory access with lower 32 bits can't be performed. What to do 
	with the higher 16 bits ???

	So to avoid this confusion, the definition of the PhysicalUpperBound 
register should be like this:-

	For the host systems where the address range is 4GB or the 
address bus width is 32 bits, the software shall write that value in the 
register which enables direct memory access with lower 32 bits. Upper 16 
bits should be 16'h0000.
	For the systems those use higher address bus width, the register 
shall be programmed accordingly. 

Regards,

Jaideep Bhatia
Senior Engineer, R&D Hardware
Wipro Infotech Limited
88, M G Road
Bangalore 560001
India

91-80- 5588422,5588667	Ext:553
jaideep@wipinfo.soft.net
From:	Jerry Hauck [Jerry_Hauck@ccm.sc.intel.com]
Sent:	Thursday, August 28, 1997 3:29 PM
To:	1394ohci-l@austin.ibm.com; aarathy@wipinfo.soft.net; valavi@wipinfo.soft.net; jaideep@wipinfo.soft.net; raomn@wipinfo.soft.net; siby@wipinfo.soft.net; simonj@wipinfo.soft.net; sukalyan@wipinfo.soft.net; tapasd@wipinfo.soft.net
Subject:	Re: cycleMatchEnable Clearing and CycleInconsistent

Siby,

I haven't seen a definitive reply to your mail message, so I thought 
I'd try and help a little.  I don't have strong arguments to support 
my position ... what follows is simply my opinion and my 
interpretation of the spec.

I assume your questions were related to Isoch Transmit rather than 
receive.  For IT DMA, OHCI was intended to perform cycle matching at 
the host side.  The description of cycleMatchEnable in Table 9-7 
supports this.

For implementations with a single Isoch Tx FIFO, it can be difficult 
to maintain strict IsoReq timings to the PHY if packets placed in the 
FIFO aren't faithfully sent.  Therefore, I claim that an unwritten 
edict of OHCI is that once an Isoch packet is queued in a hardware 
FIFO, it must be okay to always transmit.

Taken the above edict as true, it would be unwise to start sending 
Isoch packets for a few cycles and then stop due to a 
cycleInconsistent.  Consequently, I conclude that for IT DMA,

1) Matching is performed at the host side of the FIFO
2) Once a DMA context matched and starts filling the FIFO, 
cycleMatchEnable should be cleared.  Once cleared, the context can not 
be affected by a subsequent cycleInconsistent.
3) A subsequent cycleInconsistent event may cause packets scheduled in 
#2 above to go out in a cycle with a cycle number different than 
intended.
4) Once a packet is entered in the FIFO, the link is free to send it.

Hope that helps,

Jerry Hauck
Intel Corp.
(408) 765-5528
jerry_hauck@ccm.sc.intel.com

______________________________ Reply Separator _________________________________
Subject: cycleMatchEnable Clearing and CycleInconsistent
Author:  leew@austin.ibm.com at SMTPGATE
Date:    8/25/97 6:19 PM


Hi All,

When do we clear the CycleMatchEnable bit ie. 
when the counter maintained by Dma matches the 
cycleMatch or when the link side counter matches 
cycleMatch ?

These 2 counters will differ as much by the value 
of ahead_counter.

For a non-zero value of ahead counter, dma will see 
a match and load the packet corresponding to the 
context ahead of the actual link side match. Now
if a cycleInconsistent comes before the packet is 
transmitted from link, what is the expected behavior 
from link?

.94 draft of ohci says , all cyclematch Enabled contexts 
should stop on a cycleInconsistent interrupt. If this
is the case, one would assume that we can't transmit 
the packet. Further cycleMatchEnable bit may have to 
remain set in context control reg . This would mean 
we don't clear the cyclematchEnable until link side
counter gets a match (even though the packet is loaded 
in the fifo).

On the other hand, if cyclematchEnable is cleared when 
dma has got a match, the context will remain active 
even after cycleInconsistent (since there won't be
any indication of it having been enabled.)

Which is the expected behavior? Thanks in advance for 
a clarification.

Siby
From:	Vilas Bhade [vilas@wipro.com]
Sent:	Thursday, August 28, 1997 5:58 PM
To:	'Jerry_Hauck@ccm.sc.intel.com'; 1394ohci-l@austin.ibm.com
Cc:	'Siby Abraham'
Subject:	RE: cycleMatchEnable Clearing and CycleInconsistent

Jerry,

Your analogy for point 3 and 4 here I feel if there is any interruption for any reason
(This include all types of reset ) or cycleInconsistent , It should continue with the next 
context.

I guess this is what ultimately one can conclude. This is what I guess you mean by
your point 3 and point 4.

Thx and Regds
Vilas

3) A subsequent cycleInconsistent event may cause packets scheduled in 
#2 above to go out in a cycle with a cycle number different than 
intended.
4) Once a packet is entered in the FIFO, the link is free to send it.