[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