[alsa-devel] [PATCH 0/4] More aggressive PM for HD-audio

hwang4 hui.wang at canonical.com
Thu Apr 9 08:54:17 CEST 2015



On 2015年03月30日 14:53, hwang4 wrote:
>
>
> On 2015年03月27日 08:11, Hui Wang wrote:
>> On 03/26/2015 09:52 PM, Takashi Iwai wrote:
>>> At Thu, 26 Mar 2015 14:10:17 +0100,
>>> Takashi Iwai wrote:
>>>> At Thu, 26 Mar 2015 20:24:43 +0800,
>>>> Hui Wang wrote:
>>>>> On 03/21/2015 02:38 PM, Hui Wang wrote:
>>>>>> On 03/21/2015 12:20 AM, David Henningsson wrote:
>>>>>>> On 2015-03-18 09:50, Takashi Iwai wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> here is a patchset for supporting more aggressive PM for HD-audio.
>>>>>>>> This allows to change the power state of each widget more 
>>>>>>>> dynamically
>>>>>>>> with jack and stream states.  It's activated only when the codec
>>>>>>>> driver (or via sysfs or f/w patch) sets codec->power_mgmt flag.
>>>>>>>>
>>>>>>>> In theory, this should work for the recent Realtek codecs, but
>>>>>>>> currently I have no machine for test.
>>>>>>>>
>>>>>>>> David, could you or your team check whether this works for 
>>>>>>>> ALC282 or
>>>>>>>> such?  Just add like:
>>>>>>>>
>>>>>>>> --- a/sound/pci/hda/patch_realtek.c
>>>>>>>> +++ b/sound/pci/hda/patch_realtek.c
>>>>>>>> @@ -5415,6 +5415,7 @@ static int patch_alc269(struct hda_codec 
>>>>>>>> *codec)
>>>>>>>>
>>>>>>>>        spec = codec->spec;
>>>>>>>>        spec->gen.shared_mic_vref_pin = 0x18;
>>>>>>>> +    codec->power_mgmt = 1;
>>>>>>>>
>>>>>>>>        snd_hda_pick_fixup(codec, alc269_fixup_models,
>>>>>>>>                   alc269_fixup_tbl, alc269_fixups);
>>>>>>>>
>>>>>>>>
>>>>>>>> The patchset is for for-next branch of sound git tree, but they 
>>>>>>>> might
>>>>>>>> be applicable to 4.0-rc (or even older), too.  The current 
>>>>>>>> patches are
>>>>>>>> found in topic/hda-power branch.
>>>>>>> So I hoped to be able to look at this today, but it turns out the
>>>>>>> machine I was thinking of using for testing has an ALC262 codec,
>>>>>>> which hardly counts as "new".
>>>>>>>
>>>>>>> Hui, is this something you feel like taking on? Otherwise I'll 
>>>>>>> try to
>>>>>>> talk to someone in Taipei.
>>>>>>>
>>>>>> OK, I will look for the machine to do the test next week.
>>>>>>
>>>>>> Regards,
>>>>>> Hui.
>>>>>>
>>>>> Sorry for late response, today is my first day in the office back 
>>>>> from
>>>>> vacation, I checked all machines in the Beijing office, none of 
>>>>> them has
>>>>> the ALC282 codec, I will continue to look for the machine from 
>>>>> other office.
>>>>>
>>>>> And I did the test on the machines with the alc283, alc255, alc292 
>>>>> and
>>>>> alc269, the testing result were same, there were no sound output from
>>>>> internal speaker or headphone, and the internal mic or external mic
>>>>> can't record any sound. The test steps as below:
>>>>>
>>>>> 1. power_save_node = 0
>>>>> checkout the hda-power branch, build the kernel based on this branch.
>>>>> Install the kernel to the above machines and boot into the desktop
>>>>> test internal speaker and internal mic, works very well, plug a 
>>>>> headset,
>>>>> test headphone and external mic, works very well.
>>>>> run pm_suspend, wait 5 seconds, wakeup the system, redo the above 
>>>>> test,
>>>>> everything works very well.
>>>> OK, this is expected.  The patch shouldn't touch this case.
>>>>
>>>>> 2. power_save_node = 1
>>>>> enable the power_save_node as below:
>>>>> @@ -5426,6 +5426,8 @@ static int patch_alc269(struct hda_codec 
>>>>> *codec)
>>>>>
>>>>>           alc_auto_parse_customize_define(codec);
>>>>>
>>>>> +       codec->power_save_node = 1;
>>>>> +
>>>>>           if (has_cdefine_beep(codec))
>>>>>                   spec->gen.beep_nid = 0x01;
>>>>> rebuild the kernel, install the kernel to the above machines and boot
>>>>> into the desktop
>>>>> test internal speaker and internal mic, we can play sound to internal
>>>>> speaker without any errors, but I can't hear any sound from the 
>>>>> speaker;
>>>>> I can use the internal mic to record without errors, but recorded 
>>>>> file
>>>>> did not include any sound pcm (maybe all 0x00 or 0xff)
>>>>> I plug a headset into the headset jack, the detection works very 
>>>>> well,
>>>>> but I can't hear sound from headphone when play a sound, and I 
>>>>> can't use
>>>>> headset mic to record any sound as well.
>>>>>
>>>>>
>>>>> And I attached 2 alsa-info.txt, one is the power_save_node=0, the 
>>>>> other
>>>>> is the power_save_node=1
>>>> Thanks.  The alsa-info.sh outputs show no difference but the power
>>>> state, so the widget attributes seem kept with the power state change,
>>>> as it seems.
>>>>
>>>> Could you give alsa-info.sh output *during* playing with
>>>> power_save_node=1?
>>> Also, try to pull topic/hda-regmap branch in addition, and apply the
>>> patch below.  This implements the partial sync for the widget path.
>>> Note that the patch is totally untested.
>> Got it, I will do the test next Monday, since I can't access those 
>> machines until next Monday.
>>
>> Regards,
>> Hui.
>
> The attached alsa-info.txt was generated when the aplay was playing a 
> song, it seems the widget power state did not change even the output 
> device was working.
>
>
> And I also checkout the hda-regmap branch and applied the patch below, 
> rebuilt the kernel and used the kernel to do the test of playing and 
> recording, both internal devices and external devices worked very 
> well, I didn't see any obvious problems when using hda-regmap branch 
> doing the test.
>
> Regards,
> Hui.
>
Hi Takashi,

Probably I didn't express correctly, sorry to make you mis-understand.  
I wanted to express that I tested hda-power and hda-regmap two branches 
respectively, the hda-regmap branch with your patch worked very well, 
but the hda-power branch didn't work on the machines with realtek codec, 
the nodes kept in the D3 power state no matter playing or not.

It seems you enabled the power_save_node for realtek codec several days 
ago, it makes the HDA drivers fail to work on all machines with realtek 
codec.

Regards,
Hui.



More information about the Alsa-devel mailing list