Hi Stefan,
I'm sorry to be late for reply but I've been reading related specifications and check your message.
OHCI-1394
Assuming that we have an FCP controller with an OHCI link-layer controller and an FCP target with an OHCI link layer, then a typical FCP transaction would look like this (c = controller node, t = target node, req = 1394 write request packet, rsp = 1394 write response packet):
(FCP transaction request subaction) c->t req at 0xffff'f000'0b00 t->c ack_pending t->c rsp re: 0xffff'f000'0b00 c->t ack_complete (FCP transaction response subaction) t->c req at 0xffff'f000'0d00 c->t ack_pending c->t rsp re: 0xffff'f000'0d00 t->c ack_complete
I.e. one FCP transaction is typically wrapped into IEEE 1212/ IEEE 1394 split transactions. In contrast, EFC transactions are wrapped into IEEE 1212/ IEEE 1394 unified transactions (if we assume that EFC controller and EFC responder had an OHCI link layer):
(EFC transaction request subaction) c->t req at 0xecc0'0000'0000 t->c ack_complete (EFC transaction response subaction) t->c req at 0xecc0'8000'0000 c->t ack_complete
Here is a log with debug=1 for firewire-ohci.
A FCP transaction: [ 2234.652306] firewire_ohci 0000:0c:06.0: AT spd 2 tl 35, ffc1 -> ffc0, ack_pending , BW req, fffff0000b00 28,0 [ 2234.652434] firewire_ohci 0000:0c:06.0: AR spd 2 tl 35, ffc0 -> ffc1, ack_complete, W resp [ 2234.653719] firewire_ohci 0000:0c:06.0: AR spd 2 tl 36, ffc0 -> ffc1, ack_pending , BW req, fffff0000d00 128,0 [ 2234.653764] firewire_ohci 0000:0c:06.0: AT spd 2 tl 36, ffc1 -> ffc0, ack_complete, W resp
AN EFC transaction: [ 2340.506243] firewire_ohci 0000:0c:06.0: AT spd 2 tl 38, ffc1 -> ffc0, ack_pending , BW req, ecc000000000 18,0 [ 2340.506336] firewire_ohci 0000:0c:06.0: AR spd 2 tl 38, ffc0 -> ffc1, ack_complete, W resp [ 2340.506450] firewire_ohci 0000:0c:06.0: AR spd 2 tl 1f, ffc0 -> ffc1, ack_complete, BW req, ecc080000000 24,0 (fw_send_request() is canceled because (request->ack == ACK_COMPLETE))
I think EFC request is similar to FCP request, like split transaction, not unified transaction. But firewire-core handles response as unified transaction.
Link layer controllers which are *not* OHCI-1394 implementations may use one or the other 1212/ 1394 transaction type in either of the two transport protocols. Furthermore, OHCI-1394 also allows split transaction behavior to be configured for the range below 0xffff'0000'0000, but Linux' firewire-ohci and older Linux' ohci1394 configure unified transaction behavior, which is implemented by means of posted host bus writes by the OHCI. Lastly, some OHCI-1394 hardware allows addresses like the EFC range to be covered by the physical response unit, but neither firewire-ohci nor ohci1394 extend the OHCI physical response range over the EFC register range.
OK.
Anyway; the use of split or unified transactions is immaterial to the question of exclusive use versus shared use of these address ranges by the application layer.
OK. But it's nice information to me. Thank you ;)
IEEE 1212
Memory space, [0x0000'0000'0000...0xffff'e000'0000): "The name reflects a historical expectation that node resources located here exhibit behaviors usually associated with memory. That is, read and write transactions do not have side effects. In fact, any node resources may be located in this address space --- even registers with associated side effects."
That is, EFC uses Memory space. (Particularly, it uses Memory space for two vendor-defined registers with write side effects.)
Units space, [0xffff'f000'0800...0x1'0000'0000'0000): "Allocated for cooperative, shared definition by the applicable bus standard or the organizations or vendors responsible for unit architectures."
That is, FCP uses Units space.
OK.
According to this, we can do anything we want within the EFC address range (just take care that different applications do not confuse each other),
OK.
From comments in your sources (added by patch 19/52 "fireworks: Add transaction and some commands"), I guess that bytes 1...4 in EFC response frames allow applications to match response frames with request frames. If so, the implementation could be organized similarly to FCP:
It's patch 25/52. [alsa-devel] [PATCH 25/52] fireworks: Add command/response functionality into hwdep interface. http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071845.htm...
3rd quadlet in EFC transaction frame is used for sequence number. When devices receive command, they respond with sequence number increment by 1. And I confirm devices can correctly handle commands which don't has continuous sequence number.
firewire-core could allow multiple application programs (in kernelspace or in userspace) to register for listening at [0xecc0'8000'0000...0xecc0'8000'0200) and would give copies of all incoming EFC response frames to all listeners.
OK.
It would then be the responsibility of the listeners to sort out which of the responses are theirs, and which to ignore. When implemented correctly in those applications, this matching of commands and responses would work with any number of controller applications and with any number of target devices on any number of 1394 buses attached to the host.
OK.
However, there are some more considerations:
- This perhaps requires that none of the EFC controllers tell the EFC target to use an EFC_RESPONSE address other than the default, 0xecc0'8000'0000.
I'm optimistic about this issue.
The way to change the address is just via EFC command, here is no other ways. And I've already confirmed all of Fireworks models uses this address as a default, with Echo Audio's resources.
Then usual users have no chance to change the address, no chance to face changed address, unless they hope and work to do it.
- How well do Fireworks devices deal with overlapping EFC transactions? In other words, may two or even more controller applications (e.g. one streaming driver in kernelspace and one mixer UI in userspace) operate independently, or do they have to coordinate certain actions?
Fireworks devices don't mind who sends commands.
They just receive commands and send responses against them with incremented sequence number. So, like FCP applications, EFC applications need to match their command and response by the sequnce number. When any applications uses duplicated sequence number in command, matching may be failed.
To prevent from this failure, hwdep functionality of snd-fireworks check the sequence number field. If it's in the number for kernel-land, the ioctl is failed. You can see the number in include/uapi/sound/firewire.h.
But users can send EFC command via firewire character devices. There is no way to prohibit users to send command with number for kernel-land.
In firewire-core, we could hardwire shared use of [0xecc0'8000'0000...0xecc0'8000'0200) just like we hardwired shared use of FCP_COMMAND and FCP_RESPONSE. This assumes that no other application --- outside of Fireworks control applications --- attempts to use this address range.
Or we could add an in-kernel API and kernel--userspace ABI which lets applications request shared listening to an address range (in contrast to the existing API/ ABI which lets applications register for exclusive listening to an address range).
In the latter case, the userspace ABI could be either firewire-core's firewire-cdev interface, or it could be ALSA's hwdep interface.
In the former case, firewire-cdev and/or hwdep could be used as well, although firewire-cdev would be the more natural choice.
I believe ioctl with FW_CDEV_IOC_ALLOCATE is better because it's simple. I want to avoid big modification to firewire subsystem. This functionality is just for a few devices (13 models).
I understood from Clemens' comments that he intended that mixer applications should use hwdep only
- to match ALSA hwdep nodes with firewire-cdev nodes,
- to lock/ unlock streaming,
- in the future: to receive certain status information from the ALSA driver if that status is only available as in-band data from the isochronous data stream, or if that status is nowhere available because it is implicit status of write-only registers,
whereas the mixer applications are supposed to use firewire-cdev for all their other dealings with the audio devices. (Clemens and Jonathan, correct me if I misunderstood or if I forgot other control and status I/O that is only possible with direct cooperation by the ALSA driver.)
I don't know his future plan. But according to his advices, my current work is to focus on streaming driver. Currently the functionality to control device's internal mixer should be implemented in user-land application, not in ALSA drivers.
Thanks
Takashi Sakamoto o-takashi@sakamocchi.jp