patch_cm9738() still carries an old comment claiming that CMI9738
has no PCM volume although AC97_PCM reacts, and then forces
AC97_HAS_NO_PCM_VOL.

The CMI9738 datasheet documents register 0x18 as "PCM Out Vol"
with mute and left/right volume fields, so that old assumption is
not justified.

Remove the comment together with the no-PCM-volume override and let
the generic AC97 mixer code probe AC97_PCM normally. It already
checks the mute bit and the register's volume resolution before
exposing controls.

This change is intentionally limited to CMI9738.

Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
---
 sound/pci/ac97/ac97_patch.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sound/pci/ac97/ac97_patch.c b/sound/pci/ac97/ac97_patch.c
index 64cc39dd2008..5e9f70c47ed5 100644
--- a/sound/pci/ac97/ac97_patch.c
+++ b/sound/pci/ac97/ac97_patch.c
@@ -3002,9 +3002,6 @@ static const struct snd_ac97_build_ops patch_cm9738_ops = {
 static int patch_cm9738(struct snd_ac97 * ac97)
 {
 	ac97->build_ops = &patch_cm9738_ops;
-	/* FIXME: can anyone confirm below? */
-	/* CM9738 has no PCM volume although the register reacts */
-	ac97->flags |= AC97_HAS_NO_PCM_VOL;
 	snd_ac97_write_cache(ac97, AC97_PCM, 0x8000);
 
 	return 0;

---
base-commit: 116ed8afab5e3217561a6a8bc4ca1c3d5d97830c
change-id: 20260429-ac97-cmi9738-pcm-volume-898bf48a92dd

Best regards,
--  
Cássio Gabriel <cassiogabrielcontato@gmail.com>

On Wed, 29 Apr 2026 14:05:31 +0200,
Cássio Gabriel wrote:
> 
> patch_cm9738() still carries an old comment claiming that CMI9738
> has no PCM volume although AC97_PCM reacts, and then forces
> AC97_HAS_NO_PCM_VOL.
> 
> The CMI9738 datasheet documents register 0x18 as "PCM Out Vol"
> with mute and left/right volume fields, so that old assumption is
> not justified.

Well, that's actually the part the FIXME points to.  Although the spec
shows the register is available and the chip reads out, the volume
didn't seem reacting properly on the real hardware, as far as I
remember correctly.

So, it's really doubtful whether it's safe to cut off this workaround
just by reading the data sheet.


thanks,

Takashi

> 
> Remove the comment together with the no-PCM-volume override and let
> the generic AC97 mixer code probe AC97_PCM normally. It already
> checks the mute bit and the register's volume resolution before
> exposing controls.
> 
> This change is intentionally limited to CMI9738.
> 
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
> ---
>  sound/pci/ac97/ac97_patch.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/sound/pci/ac97/ac97_patch.c b/sound/pci/ac97/ac97_patch.c
> index 64cc39dd2008..5e9f70c47ed5 100644
> --- a/sound/pci/ac97/ac97_patch.c
> +++ b/sound/pci/ac97/ac97_patch.c
> @@ -3002,9 +3002,6 @@ static const struct snd_ac97_build_ops patch_cm9738_ops = {
>  static int patch_cm9738(struct snd_ac97 * ac97)
>  {
>  	ac97->build_ops = &patch_cm9738_ops;
> -	/* FIXME: can anyone confirm below? */
> -	/* CM9738 has no PCM volume although the register reacts */
> -	ac97->flags |= AC97_HAS_NO_PCM_VOL;
>  	snd_ac97_write_cache(ac97, AC97_PCM, 0x8000);
>  
>  	return 0;
> 
> ---
> base-commit: 116ed8afab5e3217561a6a8bc4ca1c3d5d97830c
> change-id: 20260429-ac97-cmi9738-pcm-volume-898bf48a92dd
> 
> Best regards,
> --  
> Cássio Gabriel <cassiogabrielcontato@gmail.com>
> 

On 4/29/26 09:39, Takashi Iwai wrote:
> On Wed, 29 Apr 2026 14:05:31 +0200,
> Cássio Gabriel wrote:
>>
>> patch_cm9738() still carries an old comment claiming that CMI9738
>> has no PCM volume although AC97_PCM reacts, and then forces
>> AC97_HAS_NO_PCM_VOL.
>>
>> The CMI9738 datasheet documents register 0x18 as "PCM Out Vol"
>> with mute and left/right volume fields, so that old assumption is
>> not justified.
> 
> Well, that's actually the part the FIXME points to.  Although the spec
> shows the register is available and the chip reads out, the volume
> didn't seem reacting properly on the real hardware, as far as I
> remember correctly.
> 
> So, it's really doubtful whether it's safe to cut off this workaround
> just by reading the data sheet.

Yes, that matches what I suspected at first glance; I wanted to confirm
whether the datasheet was enough to revisit the old workaround.

> thanks,
> 
> Takashi

-- 
Thanks,
Cássio