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)
- https://github.com/takaswie/libhinawa/tree/topic/tascam-userspace
(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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
