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

[Stefan Richter]

On Mar 01 Takashi Sakamoto wrote:
> Stefan,
> 
> At first, I introduce this is for a patch below. You can see actual logs:
> [alsa-devel] [PATCH 39/39] bebob: Add support for M-Audio special 
> Firewire series
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/073484.html

Right, I saw it (and your note that the iso resource management related
transactions still need a similar workaround).

> > It's 2000 ms actually.
> 
> Oops. Here I made a mistake to refer to unrelated value here. I might 
> consider about the other thing when writing this commit, perhaps because 
> of noon in Friday and a bit tired...
> 
> Well, yes. It's 2000 msec.
> 
> (Feb 28 2014 12:27), Takashi Sakamoto wrote:
>  > As a result, in worst case that all of three retries are timeout
>  > and devices don't send responses, fcp_avc_transaction() returns 1sec
>  > later ((200 + 125) msec * 3 times).
> 
> So in this case, this function returns 6,375msec later. (but it's rare, 
> again.)

This 125 ms part of the calculation made me wonder what the split
transaction timeout of FCP transactions is (I didn't remember), so I
looked it up and wrote down what I found.  So, all of the rest of my
reply was not really a direct comment to your patch but merely a loosely
related side note.

> > 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),
> 
> OK.

(Per IEEE 1394 specification, it should in fact also be the upper bound of
our own 1394 response timing, e.g. when we respond to FCP response frame
reception.  But we haven't implemented such a time limit for outbound 1394
response packets yet.)

> > 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.)
> 
> As You explained in this message:
> [alsa-devel] Echo Fireworks control protocol (was Re: Sample program for 
> hwdep interface)
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/071978.html
> 
> > IEC 61883-1 does not specify any FCP transaction timeout.
> 
> I've confirmed it.
> 
> > 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.

Together with the rest of the spec, it's 0..2 FCP responses, precisely.

> >    - 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.)
> 
> Additionally, there are two types of AV/C transactions, 'immediate 
> transaction' and 'deffered transaction'.

These are the first two cases in my list above.  Put into other words, here
are all possible cases of 0, 1, or 2 responses to one and the same request:

Cases with 0 responses:
  a) The target ignored a command with reserved ctype value.
  b) The target ignored a command that it received before it finished
     processing a prior command.
  c) A bus reset happened before the target had a chance to send the first
     response.  The FCP transaction specification part of the AV/C spec
     does not say what kind of effects such an aborted transaction may
     have.  Perhaps some of the various command related definitions specify
     this, I haven't looked.
  d) The specification of a particular command defines that handling of
     this command shall (or may) not be followed up by a response.  I
     haven't looked whether such commands actually exist.
Cases with 1 response:
  e) The target sends a final response as first response.
  f) The target sent an interim response as first response, but a bus reset
     happened before it could send the final response.
Cases with 2 responses:
  g) The target sends an interim response, and then a final response.  This
     is only possible with CONTROL and NOTIFY commands.

> Current 'firewire-lib' don't 
> implement 'deffered transaction' so fcp_avc_transaction() always returns 
> first AV/C response frame. This will be response=INTERIM against 
> ctype=STATUS/NOTIFY.

Correction:  CONTROL or NOTIFY.  (In contrast, STATUS or SPECIFIC INQUIRY
or GENERAL INQUIRY commands can only be performed in immediate
transactions.  See AV/C v4.2 table 19.  Likewise, already AV/C v1.0 allows
INTERIM response only to CONTROL or NOTIFY commands.)

> The gap between a first response and a second 
> response of 'deffered transaction' is defined as 'unspecified interval'.

I wonder:  Now that firewire-lib's use cases are expanded far beyond LaCie
Speakers and Griffin FireWave, do we need to implement deferred
transactions in firewire-lib too?

As far as I can tell, FFADO simply ignores INTERIM responses, and treats
deferred transactions which are completed within 200...400 ms the same way
as if it was an immediate transaction.  (This is 200 ms from
IEEE1394SERVICE_FCP_RESPONSE_TIMEOUT_USEC and 400 ms from
IEEE1394SERVICE_FCP_POLL_TIMEOUT_MSEC in the FFADO code.)

(By the way, there is another FCP transaction layer implementation
existing in the kernel:  drivers/media/firewire/firedtv-avc.c.  This one
does in fact implement deferred transactions, but only for one particular
command, SFE_VENDOR_OPCODE_REGISTER_REMOTE_CONTROL.)

A related question:  Since FFADO applies 200 ms or more as FCP transaction
timeout, shouldn't firewire-lib's fcp.c increase FCP_TIMEOUT_MS from 125
to 200 or more as well?

> But this is not related to an issue about which this patch mentions.

Right.

> (Mar 01 2014 05:39), Stefan Richter wrote:
> > To be more precise:  The specification accepts that the target*ignores*
> > incoming AV/C command frames while processing an AV/C command.  This is
> > indicated to the requester by lack of a response to any ignored request.
> >
> > To me, this implies that the target must send a response to any request
> > that it did not ignore, i.e. to any command that it executed.  On the
> > other hand, I don't think there is any rollback behavior specified or
> > practical in cases when the target is unable to deliver a response to the
> > initiator.
>  >
> >>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.
> 
> I cannot find some sections about such ignorance in 'AV/C Digital 
> Interface Command Set General Specification Version 4.2 (Sep 01, 2004, 
> 1394TA)' and 'IEC 61883-1 ed2'.
> 
> Can I request you any pointers about this ignorance?

This is about case b) and, now that I think about it, also about case a)
in my list further above.

AV/C v1.0 says about case a)...

    If the AV/C command frame contains a reserved value in the ctype
    field, the target shall ignore the command and shall not generate a
    response frame.

...and about case b):

    If the target is already occupied with a previous command, it may
    ignore any AV/C command frames received. Note that the receipt of an
    AV/C command frame shall always be acknowledged by a target. The
    target ignores a command frame by a failure to return a response frame.
    [...]
    If the target is not occupied with a previous command, it shall create
    an AV/C response frame [...]

AV/C v4.2 says about case a)...

    If the AV/C command frame contains a reserved value in the ctype
    field, the target shall ignore the command and shall not generate a
    response frame.

...and about case b):

    Before sending a first response to a command, the number of AV/C
    commands that a target can process is implementation dependent.  If the
    target cannot process an additional command, it should return a 1394
    ack_busy, ack_conflict_error, or resp_conflict_error to the additional
    command.
    NOTE – Some targets that are compliant to the previous version of this
    specification may ignore the additional command in the above case.
-- 
Stefan Richter
-=====-====- --== ----=
http://arcgraph.de/sr/