Hi Scott,
On Sep 29 2018 00:28, Scott Bahling wrote:
On Fri, 2018-09-28 at 12:44 +0900, Takashi Sakamoto wrote: Are you still thinking to try to make mmap the solution to pass the control data to userspace, or do we need to find another method in the long run?
The latter is better.
The patchset to map page frame for status and control image is just for our work to investigate. Practically, it includes several issues:
1. Due to scheduling granularity of user processes against interval to update the image, applications in the processes can fail to pick up events on the image.
2. Recently, bare embedded board with ARM cores becomes pupular. Some of them have PCIe buses. It's better for users to use units on IEEE 1394 bus, however ARM is known as cache incoherent architecture. In the architecture, page frame mapping can bring unexpected results. (See a conditional macro[1].)
For these reasons, we need to find another solution based on synchronous procedure such like read(2)/ioctl(2). For this direction, we need to care several items:
1. The status and control image includes several types of data; bitflags for physical controls of device surface, level meters and so on. Although it's acceptable to fail picking up values for level meters, it's not for physical controls.
2. TASCAM FireWire series includes below models and the layout of bitflags differs depending on them: - FW-1884 - FW-1804 - FW-1082 (FE-8 has not been investigated yet.) It cost expensive to handle such differences by kernel land in development/maintenance POV.
3. In current implementation of ALSA firewire-tascam driver, demultiplexing of OHCI 1394 isochronous packet runs on software IRQ context. Total time of software IRQ context is shared in system wide, thus it's better to reduce load as much as possible even if software IRQ run on schedulable tasks (threadedirq).
I have an idea to invervene them:
1. For control events, in kernel land, driver module detects changes of set of bitflags for physical controls, then queue events to tell the change to userspace applications (e.g. poll(2)). The queued events include information about changed bitflags (e.g. a shape of u32 data). Userspace applications execute read(2) then get the bitflags, then parse it and emit userspace event by ports in ALSA sequencer subsystem. The driver and userspace application should pay enough attention to share the queue. The driver can drop the oldest queued events if the queue is full.
2. For level meter, in kernel land, driver module caches the recent value. Userspace applications execute ioctl(2) with unique command (You can see this kind of commands in 'include/uapi/sound/firwire.h').
However, as long as I note[2], the purpose of some quadlets in the image are not still identified:
"Quadlet 00-15 show control messages. Quadlet 16-23 show analog input level. Quadlet 24-31 shows digital ADAT input level. Quadlet 32-33 shows digital S/PDIF input level. Quadlet 34-35 is unknown. Quadlet 36-43 shows analog output level. The other quadlets are unknown."
We need further investigation to clear the unknown fields as much as possible to add more codes in ALSA kernel land.
[1] https://github.com/takaswie/snd-firewire-improve/blob/topic/tascam-userspace... [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/094817.html
Thanks
Takashi Sakamoto