Linus, please do a
bk pull http://linux-sound.bkbits.net/linux-sound
The GNU patch is available at:
ftp://ftp.alsa-project.org/pub/kernel-patches/alsa-bk-2002-11-10.patch.gz
Jaroslav
This will update the following files:
include/sound/core.h | 6
include/sound/cs4231.h | 45 ++
include/sound/cs46xx.h | 83 ---
include/sound/cs46xx_dsp_spos.h | 45 +-
include/sound/info.h | 3
include/sound/pcm.h | 4
include/sound/pcm_sgbuf.h | 2
include/sound/version.h | 2
sound/core/info.c | 19
sound/core/init.c | 102 +++-
sound/core/oss/pcm_oss.c | 10
sound/core/pcm_native.c | 16
sound/core/pcm_sgbuf.c | 24 -
sound/core/rawmidi.c | 4
sound/core/seq/seq_prioq.c | 1
sound/i2c/l3/uda1341.c | 4
sound/isa/cs423x/cs4231_lib.c | 247 ++++++++---
sound/isa/es18xx.c | 8
sound/isa/sb/emu8000_pcm.c | 22 -
sound/pci/ac97/ac97_codec.c | 31 +
sound/pci/ac97/ac97_id.h | 1
sound/pci/ac97/ac97_patch.c | 12
sound/pci/ac97/ac97_patch.h | 1
sound/pci/ali5451/ali5451.c | 9
sound/pci/cs46xx/cs46xx.c | 17
sound/pci/cs46xx/cs46xx_lib.c | 751 +++++++++++++++++++++++++++++-------
sound/pci/cs46xx/cs46xx_lib.h | 33 +
sound/pci/cs46xx/dsp_spos.c | 125 +++--
sound/pci/cs46xx/dsp_spos.h | 25 +
sound/pci/cs46xx/dsp_spos_scb_lib.c | 326 +++++++++++++--
sound/pci/ens1370.c | 305 ++++++++++----
sound/pci/ice1712/ak4524.c | 178 ++++++--
sound/pci/ice1712/delta.c | 26 +
sound/pci/ice1712/delta.h | 6
sound/pci/ice1712/ews.c | 3
sound/pci/ice1712/ice1712.c | 46 --
sound/pci/ice1712/ice1712.h | 6
sound/pci/rme9652/hammerfall_mem.c | 3
sound/pci/via82xx.c | 56 +-
sound/sparc/amd7930.c | 1
sound/usb/usbaudio.c | 76 ++-
sound/usb/usbaudio.h | 11
sound/usb/usbmidi.c | 111 +++--
43 files changed, 2069 insertions(+), 737 deletions(-)
through these ChangeSets:
<[email protected]> (02/11/10 1.809)
ALSA update
- CS4231 - added sparc support to merge sparc/cs4231.c code
- ICE1712
- added support for AK4529
- added support for Midiman M-Audio Delta410
- USB driver
- fixed against newer USB API but allow compilation under 2.4
<[email protected]> (02/11/10 1.808)
ALSA update
- CS46xx driver
- DSP is started after initializing AC97 codecs
- rewrite SPDIF output stuff
- variable period size support on playback and capture
- DAC volume mechanism rewrite
- IEC958 input volume mechanism rewrite
- added "AC3 Mode Switch" in mixer
- code cleanups
- ENS1371 driver
- added definitions for the ES1373 chip
- added code to control IEC958 (S/PDIF) channel status register
<[email protected]> (02/11/10 1.807)
ALSA update
- Moved initialization of card->id to card_register() function.
The new default id is composed from the shortname given by driver.
- ES18xx - Fixed power management defines
- VIA82xx - The SG table is build inside hw_params (outside spinlock - memory allocation).
<[email protected]> (02/11/10 1.806)
ALSA update - small patches
- added kmalloc_nocheck and vmalloc_nocheck macros
- PCM
- the page callback returns 'struct page *'
- fixed delay function (moved put_user call outside spinlock)
- OSS PCM emulation
- fixed read() lock when stream was terminated and no data is available
- EMU8000
- added 'can schedule' condition to snd_emu8000_write_wait()
- AC'97
- added ALC650 support
- ALI5451
- removed double free
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
> ChangeSet 1.885.1.5, 2002/12/18 10:13:22+01:00, [email protected]
<snip>
> diff -Nru a/sound/usb/usbaudio.c b/sound/usb/usbaudio.c
> --- a/sound/usb/usbaudio.c Wed Dec 18 10:07:34 2002
> +++ b/sound/usb/usbaudio.c Wed Dec 18 10:07:34 2002
> @@ -526,7 +526,11 @@
> /*
> * complete callback from data urb
> */
> +#ifndef OLD_USB
> static void snd_complete_urb(struct urb *urb, struct pt_regs *regs)
> +#else
> +static void snd_complete_urb(struct urb *urb)
> +#endif
> {
> snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;
> snd_usb_substream_t *subs = ctx->subs;
> @@ -551,7 +555,11 @@
> /*
> * complete callback from sync urb
> */
> +#ifndef OLD_USB
> static void snd_complete_sync_urb(struct urb *urb, struct pt_regs *regs)
> +#else
> +static void snd_complete_sync_urb(struct urb *urb)
> +#endif
> {
> snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;
> snd_usb_substream_t *subs = ctx->subs;
> @@ -583,6 +591,9 @@
Ick, you're kidding me, right? Why do this? Are you trying to keep a
common code base with 2.4 and 2.5 USB drivers? If so, I don't recommend
it, as the code will be sprinkled with these ifdef's...
thanks,
greg k-h
On Wed, 18 Dec 2002, Greg KH wrote:
> > ChangeSet 1.885.1.5, 2002/12/18 10:13:22+01:00, [email protected]
>
> <snip>
>
> > diff -Nru a/sound/usb/usbaudio.c b/sound/usb/usbaudio.c
> > --- a/sound/usb/usbaudio.c Wed Dec 18 10:07:34 2002
> > +++ b/sound/usb/usbaudio.c Wed Dec 18 10:07:34 2002
> > @@ -526,7 +526,11 @@
> > /*
> > * complete callback from data urb
> > */
> > +#ifndef OLD_USB
> > static void snd_complete_urb(struct urb *urb, struct pt_regs *regs)
> > +#else
> > +static void snd_complete_urb(struct urb *urb)
> > +#endif
> > {
> > snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;
> > snd_usb_substream_t *subs = ctx->subs;
> > @@ -551,7 +555,11 @@
> > /*
> > * complete callback from sync urb
> > */
> > +#ifndef OLD_USB
> > static void snd_complete_sync_urb(struct urb *urb, struct pt_regs *regs)
> > +#else
> > +static void snd_complete_sync_urb(struct urb *urb)
> > +#endif
> > {
> > snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;
> > snd_usb_substream_t *subs = ctx->subs;
> > @@ -583,6 +591,9 @@
>
> Ick, you're kidding me, right? Why do this? Are you trying to keep a
> common code base with 2.4 and 2.5 USB drivers? If so, I don't recommend
> it, as the code will be sprinkled with these ifdef's...
Not much. We have 9 #ifdef's and all trying to resolve the conflicts with
new function prototypes which is difficult to replace with defines or
inline functions. Perhaps, you'll have an idea to solve this problem.
For us, it's very important to have only one code base for all kernels,
but on the other hand, we're trying to leave the 2.2/2.4 kernel code
specific parts separate in our CVS repository if possible.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
On Wed, Dec 18, 2002 at 08:17:55PM +0100, Jaroslav Kysela wrote:
>
> Not much. We have 9 #ifdef's and all trying to resolve the conflicts with
> new function prototypes which is difficult to replace with defines or
> inline functions. Perhaps, you'll have an idea to solve this problem.
Short of keeping a 2.4 version and a 2.5/2.6 version, no, I do not have
any ideas, sorry. The USB core has changed a lot between those two
trees, as you know.
> For us, it's very important to have only one code base for all kernels,
> but on the other hand, we're trying to leave the 2.2/2.4 kernel code
> specific parts separate in our CVS repository if possible.
Then you might want to leave the OLD_USB stuff out of the 2.5 kernel :)
thanks,
greg k-h
On Wed, 18 Dec 2002, Jaroslav Kysela wrote:
> On Wed, 18 Dec 2002, Greg KH wrote:
>
> > > ChangeSet 1.885.1.5, 2002/12/18 10:13:22+01:00, [email protected]
> >
> > <snip>
> >
> > > diff -Nru a/sound/usb/usbaudio.c b/sound/usb/usbaudio.c
> > > --- a/sound/usb/usbaudio.c Wed Dec 18 10:07:34 2002
> > > +++ b/sound/usb/usbaudio.c Wed Dec 18 10:07:34 2002
> > > @@ -526,7 +526,11 @@
> > > /*
> > > * complete callback from data urb
> > > */
> > > +#ifndef OLD_USB
> > > static void snd_complete_urb(struct urb *urb, struct pt_regs *regs)
> > > +#else
> > > +static void snd_complete_urb(struct urb *urb)
> > > +#endif
> > > {
> > > snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;
> > > snd_usb_substream_t *subs = ctx->subs;
> > > @@ -551,7 +555,11 @@
> > > /*
> > > * complete callback from sync urb
> > > */
> > > +#ifndef OLD_USB
> > > static void snd_complete_sync_urb(struct urb *urb, struct pt_regs *regs)
> > > +#else
> > > +static void snd_complete_sync_urb(struct urb *urb)
> > > +#endif
> > > {
> > > snd_urb_ctx_t *ctx = (snd_urb_ctx_t *)urb->context;
> > > snd_usb_substream_t *subs = ctx->subs;
> > > @@ -583,6 +591,9 @@
> >
> > Ick, you're kidding me, right? Why do this? Are you trying to keep a
> > common code base with 2.4 and 2.5 USB drivers? If so, I don't recommend
> > it, as the code will be sprinkled with these ifdef's...
>
> Not much. We have 9 #ifdef's and all trying to resolve the conflicts with
> new function prototypes which is difficult to replace with defines or
> inline functions. Perhaps, you'll have an idea to solve this problem.
>
> For us, it's very important to have only one code base for all kernels,
> but on the other hand, we're trying to leave the 2.2/2.4 kernel code
> specific parts separate in our CVS repository if possible.
>
> Jaroslav
>
Hello, Jaroslav and All.
How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay)
or changes with module & boot params (Rusty Russel)? There are now some
changes in 2.5.52 kernel in sound/isa/opl3sa2.c that make this driver not
compatible with other kernels. May be it's better split your tree in
several trees for each version of kernels?
Ruslan.
At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
Ruslan U. Zakirov <[email protected]> wrote:
>
> Hello, Jaroslav and All.
> How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay)
> or changes with module & boot params (Rusty Russel)? There are now some
> changes in 2.5.52 kernel in sound/isa/opl3sa2.c that make this driver not
> compatible with other kernels. May be it's better split your tree in
> several trees for each version of kernels?
if possible, we'll build up some wrapper for 2.4 on alsa-driver (not
the codebase for 2.5) tree. if not possible, yes, splitting to two
trees would be reasonable for such big changes...
thanks for noticing this issue. i'll check them now.
--
Takashi Iwai <[email protected]> SuSE Linux AG - http://www.suse.de
ALSA Developer ALSA Project - http://www.alsa-project.org
On Thu, 19 Dec 2002, Takashi Iwai wrote:
> At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
> Ruslan U. Zakirov <[email protected]> wrote:
> >
> > Hello, Jaroslav and All.
> > How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay)
> > or changes with module & boot params (Rusty Russel)? There are now some
> > changes in 2.5.52 kernel in sound/isa/opl3sa2.c that make this driver not
> > compatible with other kernels. May be it's better split your tree in
> > several trees for each version of kernels?
>
> if possible, we'll build up some wrapper for 2.4 on alsa-driver (not
> the codebase for 2.5) tree. if not possible, yes, splitting to two
> trees would be reasonable for such big changes...
>
> thanks for noticing this issue. i'll check them now.
I just removed the complete callback redefinitions from the 2.5 tree,
but we still have three small OLD_USB sections (mainly commenting 2.5
code which 2.4 code requires to override). Hopefully, it's quite reasonable.
What do you think, Greg?
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
At Wed, 18 Dec 2002 11:27:40 -0800,
Greg KH wrote:
>
> On Wed, Dec 18, 2002 at 08:17:55PM +0100, Jaroslav Kysela wrote:
> >
> > Not much. We have 9 #ifdef's and all trying to resolve the conflicts with
> > new function prototypes which is difficult to replace with defines or
> > inline functions. Perhaps, you'll have an idea to solve this problem.
>
> Short of keeping a 2.4 version and a 2.5/2.6 version, no, I do not have
> any ideas, sorry. The USB core has changed a lot between those two
> trees, as you know.
yep, i know :)
but it's also nice to keep the same codebase, because the test
environment of most of users is still on 2.4.
i'll do clean up the codes once when all major bugs are fixed.
Takashi
On Thu, 19 Dec 2002, Takashi Iwai wrote:
> At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
> Ruslan U. Zakirov <[email protected]> wrote:
> >
> > Hello, Jaroslav and All.
> > How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay)
> > or changes with module & boot params (Rusty Russel)? There are now some
> > changes in 2.5.52 kernel in sound/isa/opl3sa2.c that make this driver not
> > compatible with other kernels. May be it's better split your tree in
> > several trees for each version of kernels?
>
> if possible, we'll build up some wrapper for 2.4 on alsa-driver (not
> the codebase for 2.5) tree. if not possible, yes, splitting to two
> trees would be reasonable for such big changes...
>
> thanks for noticing this issue. i'll check them now.
If you really want single source you might use something like m4 to split
out both 2.4 and 2.5 versions which are less cluttered.
I admit this doesn't make your job a bit easier, but people reading the
drivers for one series or the other would have an easier job reading the
code. In a perfect world that would means they would find bugs for you and
just send patches. In reality you wouldn't have people telling you your
code was ugly.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Thu, Dec 19, 2002 at 01:18:10PM +0100, Jaroslav Kysela wrote:
> On Thu, 19 Dec 2002, Takashi Iwai wrote:
>
> > At Wed, 18 Dec 2002 22:51:27 +0300 (MSK),
> > Ruslan U. Zakirov <[email protected]> wrote:
> > >
> > > Hello, Jaroslav and All.
> > > How about other changes in new 2.5 kernel, like new PnP layer (Adam Belay)
> > > or changes with module & boot params (Rusty Russel)? There are now some
> > > changes in 2.5.52 kernel in sound/isa/opl3sa2.c that make this driver not
> > > compatible with other kernels. May be it's better split your tree in
> > > several trees for each version of kernels?
> >
> > if possible, we'll build up some wrapper for 2.4 on alsa-driver (not
> > the codebase for 2.5) tree. if not possible, yes, splitting to two
> > trees would be reasonable for such big changes...
> >
> > thanks for noticing this issue. i'll check them now.
>
> I just removed the complete callback redefinitions from the 2.5 tree,
> but we still have three small OLD_USB sections (mainly commenting 2.5
> code which 2.4 code requires to override). Hopefully, it's quite reasonable.
> What do you think, Greg?
In the end, whatever is easiest for you do to, as I'm not the one who
has to maintain the code :)
That being said, the smaller the number of #ifdefs, the better.
Personally I would just have two different trees, but that's just me...
thanks,
greg k-h