Comment 521 for bug 1958019

Revision history for this message
In , cam (cam-linux-kernel-bugs) wrote :

Created attachment 299745
attachment-32614-0.html

Correct, on the Legion 7i 16ITHG6 "works" out of the box, but you only
get the left channel (sounds like from both speakers too) as it seems
the 16ITHG6's firmware incorrectly initializes the amp chips during
bootup and only during bootup. Resuming from sleep results in speaker
output no longer working as there's no code to re-init the amps on the
16ITHG6 yet.

My work around from this has been to instead suspend to disk, which has
a lot of problems with the Nvidia GPU... so I run Linux in Intel
iGPUU-only mode. But with only a single audio channel, gaming isn't very
viable under Linux right now.

Additionally, in the ACPI dsdt, the amp shows up as CLSA0101 rather than
CLSA0100. Therefore applying the ALC287_FIXUP_LEGION_16ACHG6 quirk alone
to the 16ITHG6 is not enough to get it working.

I did try replacing all instances of CLSA0100 with CLSA0101 in the
patch, but that doesn't seem to work.

In my limited testing, find_comp_by_dev_name() in patch_realtek.c isn't
able to find any amp chips, which suggests to me that they're not being
detected before we even get to the realtek code. It seems all the values
in "spec->comps[i].name" are empty strings (and certainly don't match
anything like "i2c-CLSA010*:00-cs35l41-hda.*"

I'm not really sure how Linux detects devices via ACPI (or in general).
I do know there's some differences in regards to i2c on Intel Vs. AMD
(something like one has 2 i2c controllers where as the other has just
1), but I strongly suspect the kernel abstracts much of that away.

On 11/26/21 17:23, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>
> Weikai Kong (<email address hidden>) changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |<email address hidden>
>
> --- Comment #507 from Weikai Kong (<email address hidden>) ---
> Just a heads up of my results so far:
> Okay, so I compiled the latest Ubuntu unstable branch of 5.16-rc2 with a pull
> from Boonie:https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound
> plus
> patches from Lucas:
> https://patchwork.kernel.org/project/alsa-devel/list/?series=585017.
> (My fork over here:https://github.com/PIPIPIG233666/linux/commits/cs35l51)
> I am using the Intel model as well and speakers do work out of the box but
> even
> with the amplifier fixes, I don't think the amplifier is working by any
> chance.
>
> (In reply to Cameron Berkenpas from comment #505)
>> There are only 2 patches in that linked series and it seems more are
>> needed. The 2 patches do get me to a state where some of the first
>> patches in Lucas' apply, but there are rejects for the last couple of
>> patches.
>>
>> I'm patching against 5.16-rc2.
>>
>> I suppose I'll try them against sound.git.
>>
>> On 11/23/21 14:21,<email address hidden> wrote:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>>>
>>> --- Comment #503 from Marcus (kernel@m.vb1.nl) ---
>>> (In reply to Cameron Berkenpas from comment #501)
>>>> Looking at the patches, it seems that some adjustments will be needed to
>>>> make this work on the Intel model.
>>>>
>>>> Marcus,
>>>>
>>>> What tree or branch did you apply this against?
>>>>
>>>> Did you need firmware as suggested in the patch notes?
>>> I did checkout 5.16-rc2 and first patched with the patches from David
>>>
>>>
>>
>> https://patchwork.kernel<email address hidden>/
>>> and after that the patches by Lucas mentioned here.
>>>
>>> No, did not used any additional firmware. Sound is just working with these
>>> patches. Sound could be tuned by the firmwares from Lenovo probably.
>>>
> Tuning firmwares are present under Windows in C:\Windows\System32\csaudio
> while
> at it.
>