From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Serial MIDI driver for PL011 - as found on BCM2835 hardware Date: Wed, 22 Oct 2014 08:51:38 +0200 Message-ID: References: <1413847835.13334.8.camel@linux-host> <1413848459.13334.9.camel@linux-host> <54460930.6060603@zonque.org> <1413930275.13334.19.camel@linux-host> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id B3581261AF7 for ; Wed, 22 Oct 2014 08:51:38 +0200 (CEST) In-Reply-To: <1413930275.13334.19.camel@linux-host> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Kim Taylor Cc: alsa-devel@alsa-project.org, Daniel Mack List-Id: alsa-devel@alsa-project.org At Wed, 22 Oct 2014 09:24:35 +1100, Kim Taylor wrote: > > On Tue, 2014-10-21 at 09:20 +0200, Daniel Mack wrote: > > Hi, > > > > Thanks for sharing this! > > > > On 10/21/2014 01:40 AM, Kim Taylor wrote: > > > I've written a driver for raw MIDI using the PL011. It is obviously > > > based on the snd-serial-u16550 module, with a couple of improvements: > > > > > > - I've implemented a drain() callback. > > > > > > - I've also implemented a half duplex mode based on a timer callback > > > which was necessary for reliable communication with my eMagic Unitor 8 > > > hardware. (Testing with a serial link to other hardware shows that the > > > full duplex mode is also working.) > > > > So I guess you could patch the existing driver to make it work for your > > use case, right? I haven't looked at the code in detail, but from what > > you describe, that should be possible. > > I'm not sure about that. As it uses a different UART chip, there is a > new probe() function, it uses memory mapped I/O, instead of i386 > inb/outb, it gathers information from the ARM AMBA bus... > > The only things that would remain unchanged are the output_trigger() and > output_write() functions. One possibility might be to abstract out all > read/write operations using function pointers, however, I believe that > the new driver is different enough to constitute a new module. > > Or maybe there should be a third module (for example snd-serial-core, > containing any common functions, exporting them to both > snd-serial-u16550 and snd-serial-pl011? Yes, that sounds good. Of course, it depends on the volume they can share. If there are so few, no big merit to split to modules. Let's see. Takashi