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.ht...
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.ht...
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.