From alsa-devel-owner@alsa.jcu.cz  Fri Jan  8 15:03:25 1999
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id PAA26019;
	Fri, 8 Jan 1999 15:00:53 +0100
Date: Fri, 8 Jan 1999 15:00:52 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Yamahata Isaku <yamahata@kusm.kyoto-u.ac.jp>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: serial midi
In-Reply-To: <19990108105054.A14672@ray.kusm.kyoto-u.ac.jp>
Message-ID: <Pine.LNX.3.96.990108145201.2806E-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Fri, 8 Jan 1999, Yamahata Isaku wrote:

> Hello.
> 
>  I ported serial midi patch for Open Sound System to ALSA,
> and attached to this mail.
> Extract archive to source tree of alsa-driver.
> Edit lowlevel/general/Makefile,card/Makefile and compile it.
> 
> serial midi patch for OSS
> http://crystal.apana.org.au/~ghansper/MidiAxis.html
> 
> TODO
>  - license
>    Serial midi patch for OSS is distributed under BSD-like license.
>    I emailed to Hansper, the auther of original patch, for permition of
>    distributing this under GNU GPL, now waiting for his replay. 

OK. ALSA contains only GNU GPL code and I don't want change it. Until
author of original patch doesn't confirm GNU GPL, I don't include this
code to ALSA sources.

>  - 32channel(2port)
>  - test
>    I tested only output on 2.0.36.
>  - How should we handle irq?
>    In ALSA irq is requested when module is loaded, and release
>    when unloading by snd_register_irq,snd_unregister_irq.
>    but currently, irq is requested when device is opened,
>    freed when device is closed, as original does.

I preffer use resource allocation by initialization of module.
You can reach two situations with IRQ allocation:

1) ISA (non-shared)
   - this IRQ cannot be shared with other device, thus locking
     (immediate allocation) of this resource is good idea
2) PCI (shared)
   - shared interrupts don't depends on others, thus we can
     allocate this resource in any time without side effects

>  - How should we handle ioport?

It's same thing as IRQ resource. Available functions:

snd_register_ioport
snd_unregister_ioport
snd_unregister_ioports

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic


