Hi,
Attached is a small patch to enable the built-in mic boost
of the ac97_codec. On my SB-live, it needs this to get
decent mic volume and I imagine this is the case for some
other cards as well. It maps the micboost to
SOUND_MIXER_AGC which, well, isn't used for anything else
at present that I know of.
Applies to 2.4.21-rc2.
S
diff -urN linux.orig/drivers/sound/ac97_codec.c linux/drivers/sound/ac97_codec.c
--- linux.orig/drivers/sound/ac97_codec.c 2003-05-12 15:50:07.000000000 -0700
+++ linux/drivers/sound/ac97_codec.c 2003-05-12 15:50:52.000000000 -0700
@@ -400,6 +400,18 @@
if (left >= mh->scale)
left = mh->scale-1;
val |= left & 0x000e;
+ } else if (oss_channel == SOUND_MIXER_MIC) {
+ val = codec->codec_read(codec , mh->offset) & ~0x801f;
+ if (!left)
+ val |= AC97_MUTE;
+ else {
+ left = ((100 - left) * mh->scale) / 100;
+ if (left >= mh->scale)
+ left = mh->scale-1;
+ val |= left;
+ /* the low bit is optional in the tone sliders and masking
+ it lets us avoid the 0xf 'bypass'.. */
+ }
} else if(left == 0) {
val = AC97_MUTE;
} else if (oss_channel == SOUND_MIXER_SPEAKER) {
@@ -418,14 +430,6 @@
if (left >= mh->scale)
left = mh->scale-1;
val = left;
- } else if (oss_channel == SOUND_MIXER_MIC) {
- val = codec->codec_read(codec , mh->offset) & ~0x801f;
- left = ((100 - left) * mh->scale) / 100;
- if (left >= mh->scale)
- left = mh->scale-1;
- val |= left;
- /* the low bit is optional in the tone sliders and masking
- it lets us avoid the 0xf 'bypass'.. */
}
#ifdef DEBUG
printk(" 0x%04x", val);
@@ -574,6 +578,15 @@
codec->recmask_io(codec, 0, val);
return 0;
+ case _IOC_NR(SOUND_MIXER_AGC): {
+ u16 r = codec->codec_read(codec, AC97_MIC_VOL);
+ if (val)
+ r |= AC97_MICBOOST;
+ else
+ r &= ~AC97_MICBOOST;
+ codec->codec_write(codec, AC97_MIC_VOL, r);
+ return 0;
+ }
default: /* write a specific mixer */
i = _IOC_NR(cmd);
This fixes a buglet wrt doing vmalloc at interrupt time for 2.4.
get_vm_area should call kmalloc with GFP_ATOMIC- after all, it's
set up to allow for an allocation failure. As best as I read
the 2.4 code, the rest of the path through _kmem_cache_alloc
should be safe.
===== vmalloc.c 1.15 vs edited =====
--- 1.15/mm/vmalloc.c Wed Feb 12 05:30:56 2003
+++ edited/vmalloc.c Fri May 9 23:42:09 2003
@@ -173,7 +173,7 @@
unsigned long addr, next;
struct vm_struct **p, *tmp, *area;
- area = (struct vm_struct *) kmalloc(sizeof(*area), GFP_KERNEL);
+ area = (struct vm_struct *) kmalloc(sizeof(*area), GFP_ATOMIC);
if (!area)
return NULL;
On Tue, May 13, 2003 at 02:11:12PM -0700, Matthew Jacob wrote:
>
> This fixes a buglet wrt doing vmalloc at interrupt time for 2.4.
vmalloc/vfree is not allowed from interrupt context. the GFP flag
is the least of your worries.
On Tue, May 13, 2003 at 02:11:12PM -0700, Matthew Jacob wrote:
> This fixes a buglet wrt doing vmalloc at interrupt time for 2.4.
> get_vm_area should call kmalloc with GFP_ATOMIC- after all, it's
> set up to allow for an allocation failure. As best as I read
> the 2.4 code, the rest of the path through _kmem_cache_alloc
> should be safe.
Try write_lock_irq(&vmlist_lock)/read_lock_irq(&vmlist_lock) and
passing in a gfp mask with an alternative API etc. for the interrupt
time special case. It's deadlockable without at least the locking bits.
But it's worse than that, the implicit smp_call_function() means this
is stillborn and infeasible period.
-- wli
Ah. Thanks.
On Tue, 13 May 2003, William Lee Irwin III wrote:
> On Tue, May 13, 2003 at 02:11:12PM -0700, Matthew Jacob wrote:
> > This fixes a buglet wrt doing vmalloc at interrupt time for 2.4.
> > get_vm_area should call kmalloc with GFP_ATOMIC- after all, it's
> > set up to allow for an allocation failure. As best as I read
> > the 2.4 code, the rest of the path through _kmem_cache_alloc
> > should be safe.
>
> Try write_lock_irq(&vmlist_lock)/read_lock_irq(&vmlist_lock) and
> passing in a gfp mask with an alternative API etc. for the interrupt
> time special case. It's deadlockable without at least the locking bits.
>
> But it's worse than that, the implicit smp_call_function() means this
> is stillborn and infeasible period.
>
>
>
> -- wli
>
On Tue, May 13, 2003 at 02:17:07PM -0700, William Lee Irwin III wrote:
> On Tue, May 13, 2003 at 02:11:12PM -0700, Matthew Jacob wrote:
> > This fixes a buglet wrt doing vmalloc at interrupt time for 2.4.
> > get_vm_area should call kmalloc with GFP_ATOMIC- after all, it's
> > set up to allow for an allocation failure. As best as I read
> > the 2.4 code, the rest of the path through _kmem_cache_alloc
> > should be safe.
>
> Try write_lock_irq(&vmlist_lock)/read_lock_irq(&vmlist_lock) and
> passing in a gfp mask with an alternative API etc. for the interrupt
> time special case. It's deadlockable without at least the locking bits.
>
> But it's worse than that, the implicit smp_call_function() means this
> is stillborn and infeasible period.
Not to mention the page table allocation code...
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Maw, 2003-05-13 at 22:11, Matthew Jacob wrote:
> This fixes a buglet wrt doing vmalloc at interrupt time for 2.4.
>
> get_vm_area should call kmalloc with GFP_ATOMIC- after all, it's
> set up to allow for an allocation failure. As best as I read
> the 2.4 code, the rest of the path through _kmem_cache_alloc
> should be safe.
You aren't allow to vmalloc in an IRQ. The kmalloc is the least of
your programs - you have to worry about the page table handling.
On Maw, 2003-05-13 at 23:34, Alan Cox wrote:
> On Maw, 2003-05-13 at 22:11, Matthew Jacob wrote:
> > This fixes a buglet wrt doing vmalloc at interrupt time for 2.4.
> >
> > get_vm_area should call kmalloc with GFP_ATOMIC- after all, it's
> > set up to allow for an allocation failure. As best as I read
> > the 2.4 code, the rest of the path through _kmem_cache_alloc
> > should be safe.
>
> You aren't allow to vmalloc in an IRQ. The kmalloc is the least of
> your programs - you have to worry about the page table handling.
problems even. 1am isnt the best time for posting ;)