From: hwang4 <hui.wang@canonical.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org,
David Henningsson <david.henningsson@canonical.com>
Subject: Re: [PATCH 0/4] More aggressive PM for HD-audio
Date: Thu, 09 Apr 2015 14:54:17 +0800 [thread overview]
Message-ID: <55262219.6040406@canonical.com> (raw)
In-Reply-To: <5518F2F1.90306@canonical.com>
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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2015-04-09 6:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-18 8:50 [PATCH 0/4] More aggressive PM for HD-audio Takashi Iwai
2015-03-18 8:50 ` [PATCH 1/4] ALSA: hda - Simplify PCM setup overrides Takashi Iwai
2015-03-18 8:50 ` [PATCH 2/4] ALSA: hda - Support advanced power state controls Takashi Iwai
2015-03-18 8:50 ` [PATCH 3/4] ALSA: hda - Use the new power control for VIA codecs Takashi Iwai
2015-03-18 8:50 ` [PATCH 4/4] ALSA: hda - Adjust power of beep widget and outputs Takashi Iwai
2015-03-18 19:34 ` [PATCH 0/4] More aggressive PM for HD-audio David Henningsson
2015-03-18 20:02 ` Takashi Iwai
2015-03-20 16:20 ` David Henningsson
2015-03-20 16:28 ` Takashi Iwai
2015-03-20 17:18 ` Takashi Iwai
2015-03-20 17:33 ` Takashi Iwai
2015-03-21 6:38 ` Hui Wang
[not found] ` <5513FA8B.402@canonical.com>
2015-03-26 13:10 ` Takashi Iwai
2015-03-26 13:52 ` Takashi Iwai
2015-03-27 0:11 ` Hui Wang
2015-03-30 6:53 ` hwang4
2015-04-04 10:31 ` Takashi Iwai
2015-04-09 6:54 ` hwang4 [this message]
2015-04-09 6:56 ` Takashi Iwai
2015-04-09 6:59 ` David Henningsson
2015-04-09 8:35 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55262219.6040406@canonical.com \
--to=hui.wang@canonical.com \
--cc=alsa-devel@alsa-project.org \
--cc=david.henningsson@canonical.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox