Hi Scott,
On Sep 24 2018 18:32, Scott Bahling wrote:
On Mon, 2018-09-17 at 23:36 +0900, Takashi Sakamoto wrote:
I prepare branches in two remote repositories:
https://github.com/takaswie/snd-firewire-improve/tree/topic/tascam-userspace
(a384019c0f78)
(a5994ec2165f)
Installing the patched driver, you can read the status and control message in userspace by mmap(2).
Patched libhinawa produces HinawaSndTscm GObject class. This class is also available with gobject introspection. For example with PyGobject:
... Thanks! I finally had some time to try it out.
My test system is running a 4.12 kernel from openSUSE Leap 15.0. I backported the patches but had to remove your GFP_KERNEL patch for it to work on my kernel. With the GFP_KERNEL patch, user space was not seeing updates to the data stream. With it removed, I had a constant update.
The kernel was unstable and the system hard locked frequently with the patches enabled (with and without the GFP_KERNEL patch). But I was able to map out all the controller functions to the bits in the first 16 quadlets. I will write up my findings and send them later.
I'm sorry but I have applied wrong changes to the remote branch for kernel patch. It includes three issues:
1. call vfree() to memory object allocated by kmalloc() 2. bring kernel oops due to double free corruption of 'tscm->status' 3. invalid page mapping of 'tscm->status' to process' VMA
I pushed additional three patches. Would you please test with them?
- 1777454 firewire-tascam: fix kernel oops to call vfree() to memory object allocated by kmalloc - e11d941 firewire-tascam: fix double free corruption - 5e7fef9 firewire-tascam: use one page for mmap(2)ed data
Espeially, when allocating in kernel logical space instead of kernel virtual space, I should have kept one page for 'tscm->status' because kmalloc() allocates memory object unaligned to page boundary by kernel SLAB/SLOB/SLUB allocaters. This is a cause which you cannot see updated data. A page mapped to process' VMA doesn't include region of 'tscm->status' data correctly.
Again, I'm sorry to lost your time due to this kind of my stupid codes...
I noticed that we are able to control the LEDs from the host via the asynchronous link. Do you you think the faders are also controlled that way or would that also go via isochronous packets to the FW-1884?
The rx isochronous packets from system to the unit include no data to control the unit[2]. If the faders are movable from system software, it should be achieved by asynchronous transactions, like blighting LEDs.
I guess without an analyzer that will be difficult to track down.
Thanks
Takashi Sakamoto