[alsa-devel] [PATCH 18/39] firewire-lib: Add a fallback at RCODE_CANCELLED

[Stefan Richter]

On Feb 28 Takashi Sakamoto wrote:
> Linux Firewire Subsystem currently gives
> 200msec for default timeout (See DEFAULT_SPLIT_TIMEOUT in core-card.c).

It's 2000 ms actually.

And this is the IEEE 1394 split transaction timeout of course.  FCP
transactions on the other hand are transported by means of two IEEE 1394
transactions:  One in which the FCP requester is IEEE 1394 requester, and
another one in which the FCP responder is IEEE 1394 requester.

firewire-core's split transaction timeout is only relevant to the request
subaction of an FCP transaction (i.e. the first one of the two IEEE 1394
transaction), and only if this one is being performed as a split
transaction rather than a unified transaction, which depends on the FCP
responder hardware.  (I am not aware of any hardware which handles
FCP request subactions as unified transactions.)

IEC 61883-1 does not specify any FCP transaction timeout.

The 1394 TA document "AV/C Digital Interface Command Set, Rev. 1.0,
1996" defines FCP transactions (for use with AV/C command set) much more
precisely than IEC 61883-1 does:

  - To each FCP request, there may be 0..n FCP responses.

  - An AV/C target may emit a final response (one with response code <
    0xf) up to 100 ms after reception of an FCP request.

  - Or the AV/C target may emit an intermediate response (one with
    response code 0xf for interim response) up to 100 ms after reception
    of an FCP request.  The target shall emit no additional interim
    response in this transaction, but one final response.  There is no
    timeout specified for this final-after-interim response, i.e. it may
    take an undefined, possibly very long time.  (The AV/C
    specification v4.0, 2001 adds that subunit specifications may define
    such timeouts for certain commands.)

  - Or the AV/C target may still be busy processing a previous command.
    In this case, the specification accepts that the target does not send
    any response to subsequent requests at all until it is done with the
    previous work.  The requester may the retry such a failed request after
    the mentioned 100 ms timeout.  (Plus IEEE 1394 transport overhead, but
    the AV/C specification v1.0 does not mention this.  AV/C v4.0 explains
    that the requester should take certain transport dependent delays
    into account in addition to the 100 ms FCP timeout, e.g. physical layer
    repeater delays, or busy retry delays.  Furthermore, AV/C v4.0
    recommends that a busy target returns certain acknowledge codes or
    response codes to pipelined requests that exceed its capacity
    to handle concurrent FCP transactions.)

  - An "IEEE 1394.0 reset" (sic) terminates any outstanding FCP transaction.
    (I suppose a 1394 bus reset is meant by this.  AV/C v4.0 clarifies this
    to be an IEEE 1394 bus reset indeed.)

From a quick glance, the FCP transaction specification looks unchanged
from AV/C 4.0, 2001 to v4.1, 2001 and to v4.2, 2004.
-- 
Stefan Richter
-=====-====- --=- ===--
http://arcgraph.de/sr/