public inbox for alsa-devel@alsa-project.org
 help / color / mirror / Atom feed
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

  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