2.4 ac97_codec micboost control

PATCH New Shane Wegner 6 participants 8 messages May 12, 2003 – May 14, 2003

Subsystems (2)

Memory management vmalloc

lore

Share & tools

lore

Shane Wegner

author

2003-05-12 22:44 UTC #0 lore raw

PATCH 1/1 2.4 ac97_codec micboost control

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.

drivers/sound/ac97_codec.c +21 -8

diff -urN linux.orig/drivers/sound/ac97_codec.c linux/drivers/sound/ac97_codec.c
@@ -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);

Matthew Jacob

2003-05-13 20:58 UTC #1 lore raw

PATCH 1/1 2.4 fix to allow vmalloc at interrupt time

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 =====

vmalloc.c renamed from mm/vmalloc.c +1 -1

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

William Lee Irwin III

2003-05-13 21:04 UTC #2 lore raw

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

Quoted 5 lines · 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.

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

Matthew Jacob

2003-05-13 21:16 UTC #3 lore raw

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

Ah. Thanks.

Quoted 18 lines · William Lee Irwin III

Quoted 5 lines · 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.
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

Russell King

2003-05-13 22:30 UTC #4 lore raw

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

In reply to William Lee Irwin III

Quoted 7 lines · William Lee Irwin III

Quoted 5 lines · 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.

Quoted 6 lines

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...

Signature · 2 lines

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Christoph Hellwig

2003-05-13 21:05 UTC #5 lore raw

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

In reply to Matthew Jacob

Quoted 2 lines · Matthew Jacob

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.

Alan Cox

2003-05-13 23:19 UTC #6 lore raw

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

In reply to Matthew Jacob

Quoted 6 lines · 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.

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.

Alan Cox

2003-05-14 00:07 UTC #7 lore raw

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

Quoted 10 lines · Alan Cox

Quoted 6 lines · 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.
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 ;)