Subject: OHCI Anamolies

From: venkatesh v <[email-masked]>
Date: Fri, 18 Jun 1999 04:28:51 -0700

Hello OHCI Gurus !

Back with some small doubts about documentation
in OHCI Draft 1.00 with regards to timestamp for
AT Response cases (in the DMA Descriptors)

Section 7.1.5.3.3 (Pg 68) states that
"A timestamp value can be placed in the first
OUTPUT_* descriptor for such packets to indicate
expirationt time"

I guess this means OUTPUT_LAST_IMM and OUTPUT_MORE_IMM.

While going through the field descriptions for
OUTPUT_LAST_IMM (Table 7.4 Pg 66)
"For AT response packets, timeStamp is not valid
(Response descriptor block use a timeStamp in the
*-Immediate descriptor)"

In the case of field description for OUTPUT_MORE_IMM
the timeStamp field is valid and it indicates the
time after which the packet should not be transmitted.

Doubt: If the response packet needs to use OUTPUT_LAST_IMM desc only..
where do I set this
timeStamp ??

We have one observation, when we write a timeStamp
of 0xffff in the timeStamp field, the value reflected
in the DMA Descriptors are different in different
cases
a) We write 0xffff, so that AT Response succeeds
   without an event_timeout. What are the consequences
   of writting this value ??
b) We wrote 0xff40 (7secs, 8000 cycles) without
   any success.

Greatly appreciate a quick AT Response before event_timeout.

For a few folks... have a nice weekend !!

Adios

Venkatesh

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: "R.Ramakrishnan" <[email-masked]>
Date: Fri, 18 Jun 1999 17:14:44 -0230

Hi,

>Doubt: If the response packet needs to use OUTPUT_LAST_IMM desc only..

   You should set the timeStamp value in the OUTPUT_LAST Immediete
descriptor itself. That is what document says.

>   of writting this value ??
    It depends on the current cycle timer value(Look at 5.12). If the
difference between this field and the cycle timer value is 1 second, the
packet might get timed out. This is because the fairness interval value will
come into picture for the local node to be arbitrate for sending the
response.

>b) We wrote 0xff40 (7secs, 8000 cycles) without
    What you can do is, get the current cycle timer value and add 2 (or) 3
seconds to it and set it again.
I think this is the way we have to do it. (or) otherwise find the optimal
value from the gapcount value of your node. The value you can calculate by
using the table given in the IEEE 1394 specification.

Regards
Ramki

---

From: Diana Klashman - Sun BOS Software <[email-masked]>
Date: Fri, 18 Jun 1999 13:40:18 -0400

>(Response descriptor block use a timeStamp in the

I think there's been some confusion here.  Table 7-4 for
OUTPUT_LAST_Imm is on page 68.  The quote above regarding
timestamp is for OUTPUT_LAST, and is in Table 7-3 pg 67.
I believe the spec is correct as-is.

>b) We wrote 0xff40 (7secs, 8000 cycles) without

I'm not sure I understand what you are trying to do.  The idea
behind setting a timestamp for responses is to ensure the response
is not sent after a SPLIT_TIMEOUT expires for the request.  So what you
need to do is pick up the timestamp from the incoming request, then add
SPLIT_TIMEOUT time to it, and put this value in the timestamp field
when transmitting the corresponding response.

The timestamp is _not_ a "duration" of time, but is the actual bus
time before which the packet must be transmitted.

If you are trying to, in effect, bypass this ohci feature, you could
read the isoch cycle timer register just before queueing it, add
a reasonable time delta, then send it out.  I don't know why you'd
want to do that though.

Diana

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Diana Klashman              email: [email-masked] |
| Staff Engineer              phone: (781) 442-0575        |
| Sun Microsystems              fax: (781) 442-1672        |
| 1 Network Drive          mailstop: UBUR03-302            |
| Burlington, MA 01803                                     |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-