Alsa-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org, clemens@ladisch.de,
	ffado-devel@lists.sf.net
Subject: Re: [PATCH 18/39] firewire-lib: Add a fallback at RCODE_CANCELLED
Date: Sat, 01 Mar 2014 12:18:19 +0900
Message-ID: <5311517B.5060905@sakamocchi.jp> (raw)
In-Reply-To: <20140228212535.7606e0d8@stein>

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

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

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

> 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.
>
>    - 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'. 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.  The gap between a first response and a second 
response of 'deffered transaction' is defined as 'unspecified interval'.

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

(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?


Thanks

Takashi Sakamoto
o-takashi@sakamocchi.jp

  parent reply index

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28  3:27 [GIT PULL][PATCH 00/39] Enhancement of support for Firewire devices Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 01/39] firewire-lib: Rename functions, structure, member for AMDTP Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 02/39] firewire-lib: Add macros instead of fixed value " Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 03/39] firewire-lib: Add 'direction' member to 'amdtp_stream' structure Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 04/39] firewire-lib: Split some codes into functions to reuse for both streams Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 05/39] firewire-lib: Add support for AMDTP in-stream and PCM capture Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 06/39] firewire-lib: Add support for MIDI capture/playback Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 07/39] firewire-lib: Give syt value as parameter to handle_out_packet() Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 08/39] firewire-lib: Add support for duplex streams synchronization in blocking mode Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 09/39] firewire-lib: Add sort function for transmitted packet Takashi Sakamoto
2014-02-28  6:40   ` Takashi Iwai
2014-02-28 14:31     ` Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 10/39] firewire-lib: Add transfer delay to synchronized duplex streams Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 11/39] firewire-lib: Add support for channel mapping Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 12/39] firewire-lib: Rename macros, variables and functions for CMP Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 13/39] firewire-lib: Add 'direction' member to 'cmp_connection' structure Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 14/39] firewire-lib: Add handling output connection by CMP Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 15/39] firewire-lib: Add a new function to check others' connection Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 16/39] firewire-lib: Add some AV/C general commands Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 17/39] firewire-lib: Add quirks for Fireworks Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 18/39] firewire-lib: Add a fallback at RCODE_CANCELLED Takashi Sakamoto
2014-02-28 20:25   ` Stefan Richter
2014-02-28 20:39     ` Stefan Richter
2014-03-01  3:18     ` Takashi Sakamoto [this message]
2014-03-01 10:10       ` Stefan Richter
2014-03-01 12:22         ` Takashi Sakamoto
2014-03-01 14:20           ` Stefan Richter
2014-03-04  1:35             ` [FFADO-devel] " Jonathan Woithe
2014-03-04  8:33               ` Stefan Richter
2014-03-04  9:28                 ` Stefan Richter
2014-03-01 10:34   ` Stefan Richter
2014-03-01 12:23     ` Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 19/39] fireworks: Add skelton for Fireworks based devices Takashi Sakamoto
2014-02-28  6:51   ` Takashi Iwai
2014-02-28 15:05     ` Takashi Sakamoto
2014-02-28 15:10       ` Takashi Iwai
2014-02-28 15:36         ` Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 20/39] fireworks: Add transaction and some commands Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 21/39] fireworks: Add connection and stream management Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 22/39] fireworks: Add proc interface for debugging purpose Takashi Sakamoto
2014-02-28  6:54   ` Takashi Iwai
2014-03-01 13:17     ` Takashi Sakamoto
2014-03-03  9:01       ` Takashi Iwai
2014-03-04 14:10         ` Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 23/39] fireworks: Add MIDI interface Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 24/39] fireworks: Add PCM interface Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 25/39] fireworks: Add hwdep interface Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 26/39] fireworks: Add command/response functionality into " Takashi Sakamoto
2014-02-28  6:58   ` Takashi Iwai
2014-03-01 13:18     ` Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 27/39] bebob: Add skelton for BeBoB based devices Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 28/39] bebob: Add commands and connections/streams management Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 29/39] bebob: Add proc interface for debugging purpose Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 30/39] bebob: Add MIDI interface Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 31/39] bebob: Add PCM interface Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 32/39] bebob: Add hwdep interface Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 33/39] bebob: Prepare for device specific operations Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 34/39] bebob: Add support for Terratec PHASE, EWS series and Aureon Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 35/39] bebob: Add support for Yamaha GO series Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 36/39] bebob: Add support for Focusrite Saffire/SaffirePro series Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 37/39] bebob: Add support for M-Audio usual Firewire series Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 38/39] bebob: Send a cue to load firmware for M-Audio " Takashi Sakamoto
2014-02-28  3:27 ` [PATCH 39/39] bebob: Add support for M-Audio special " Takashi Sakamoto
2014-03-01 10:53   ` Stefan Richter
2014-03-01 13:06     ` Takashi Sakamoto
2014-03-01 14:32       ` Stefan Richter
2014-02-28  6:36 ` [GIT PULL][PATCH 00/39] Enhancement of support for Firewire devices Takashi Iwai
2014-03-01 13:14   ` Takashi Sakamoto
     [not found] <5316963F.1000206@sakamocchi.jp>
2014-03-05 10:47 ` [GIT PULL][PATCH 00/39 v2] " Takashi Sakamoto
2014-03-05 10:48   ` [PATCH 18/39] firewire-lib: Add a fallback at RCODE_CANCELLED Takashi Sakamoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5311517B.5060905@sakamocchi.jp \
    --to=o-takashi@sakamocchi.jp \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    --cc=ffado-devel@lists.sf.net \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Alsa-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/alsa-devel/0 alsa-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 alsa-devel alsa-devel/ https://lore.kernel.org/alsa-devel \
		alsa-devel@alsa-project.org
	public-inbox-index alsa-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.alsa-project.alsa-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git