[alsa-devel] Controlling the Tascam FW-1884

[Takashi Sakamoto]

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