[patch] 2.4 ac97_codec micboost control

[patch] 2.4 ac97_codec micboost control

[Shane Wegner]

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);
 

[patch] 2.4 fix to allow vmalloc at interrupt time

[Matthew Jacob]

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;

Re: [patch] 2.4 fix to allow vmalloc at interrupt time

[William Lee Irwin III]

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

Re: [patch] 2.4 fix to allow vmalloc at interrupt time

[Christoph Hellwig]

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.

Re: [patch] 2.4 fix to allow vmalloc at interrupt time

[Matthew Jacob]

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
>

Re: [patch] 2.4 fix to allow vmalloc at interrupt time

[Alan Cox]

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.

Re: [patch] 2.4 fix to allow vmalloc at interrupt time

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [patch] 2.4 fix to allow vmalloc at interrupt time

[Alan Cox]

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 ;)