Comment 262 for bug 1958019
Revision history for this message
|
|
#262 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
On 6/22/21 3:05 PM, <email address hidden> wrote:
> https:/
>
> --- Comment #247 from woody64 (<email address hidden>) ---
> (In reply to TT from comment #236)
>> I experienced the same as Comment #230 and Comment #231 in Ubuntu 20.04.2
>> kernel 5.8.0-55.
>>
>> BTW, have you seen this windows program to get the dumps? RtHDDump_V236.zip
>> It is suggested suggested by Hui Wang that has contributions to the Realtek
>> patches. Sources:
>> - https:/
>> - https:/
>> - https:/
>> I have windows installed in another partition and may try it later.
>> We may have already the coeffs to make it work but this may show something
>> extra.
> I've tried to follow some ideas in the dump. Don't know if that brings
> anybody
> further insights.
How direct can the dumps be translated to verbs? If translating isn't an
issue (I don't know what the dump output looks like yet but I should
really look), that should be a sufficient set of verbs to get both
speakers going in a patch for the Yoga.
Hopefully the dumps are a working alternative to running a Windows VM
with PCIE passthrough... It's quite a bit of work to setup.
>
> # 1. enables output of COEF
> echo 1 |sudo tee /sys/module/
> # shows the result for the ALC287
> cat /proc/asound/
> # thus allowing to dump the different COEF register states after several
> actions
>
> => if I'm comparing the output before and after S3 resume, I can't see a
> significant difference
>
> # 2. enable hda traces
> echo 1 | sudo tee /sys/kernel/
> # read traces
> sudo cat /sys/kernel/
> # result in output like:
> # alsa-sink-HDA A-1107 [000] .... 9249.632894: hda_send_cmd:
> [0000:00:1f.3:0] val=0x00170500
> hda-decode-verb 0x00170500
> raw value = 0x00170500
> cid = 0, nid = 0x01, verb = 0x705, parm = 0x00
> raw value: verb = 0x705, parm = 0x0
> verbname = set_power_state
I think these traces will very useful. Perhaps I can also use them to
determine what's going on when I plug headphones into the jack and
remove them so we can handle that appropriately.
>
> My main idea is that there must something happen after a S3 resume which
> leads
> to a working speaker config, and it must be in the driver code?
>
> I've tried to catch that and will upload the results soon ...
>
> Additionally looking in the kernel code you see:
> - HDA_CODEC_
> - for alc269 you find
> - codec->
> - in alc269_resume:
> /* on some machine, the BIOS will clear the codec gpio data when enter
> * suspend, and won't restore the data after resume, so we restore it
> * in the driver.
> */
>
> => would explain, why S3 resume is working
> - maybe some additonal toggle_power_output commands are also helpful
Well, this is like the other issue with my patch where after unplugging
headphones, speaker output is gone again and can be restored by either
applying the verbs or a *resume*.
I did notice that resume seems to call init for the card again (which
applies to the verbs that are in the patch), but the fact that this
worked for the Yoga Slim *before* my patch and gets both speakers to
come up *after* the patch makes me think there might be something in the
firmware/BIOS. Maybe Lenovo was running into an issue on resume and the
firmware/BIOS re-initializes the speakers as a workaround? Or maybe it
is something in the driver? But AFAIK, looking through the kernel code,
resume just seems to call the init function IIRC.
And maybe this is why S3 has to be enabled by editing the DSDT table; it
was giving Lenovo some trouble?
>
>
>
> Is that something which can be helpful or a complete misleading path?
I think all of this is helpful, and I'm very grateful to have another
pair of eyes on this. Thank you!
On an unrelated note, I sent a message to alsa-devel (I signed up first)
and so far no bites. However, maybe a lot of them in Europe (I'm in the
US) and perhaps I'll see some responses by morning..?