Comment 760 for bug 1958019

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

Yes, I confirm that the patch includes the slim 7 in the list of fixups, with the right "16IAH7" model number and right numeric id: 0x17aa:0x3803 (same as my alsa-info), so I thought there was some success for this computer. But rewinding the discussion to the top in this thread and the other one (https://bugzilla.kernel.org/show_bug.cgi?id=216194) doesn't show any evidence of success for the "slim" variant. Or maybe I missed it?
I noticed that the clear text name for the entry in the patch is named "Legion 7" not "Legion S7". Maybe there's some mismatch here? I mean: could the slim references have been used in place of another model, maybe another 7 variant? Lenovo's naming scheme is confusing: there's the 7, the 7i, the 7 Pro and the S7 which is either named S7 (without "i" no matter Intel or AMD) or Slim 7 (only AMD) or Slim 7i (only Intel).

I understand the issue with DSD and why it's frustrating. This isn't by far the first frustration I get with this kind of issue... But fortunately these little issues are more than balanced by the benefits of running Linux :-)

Using 6.2.1 on my slim 7i (16IAH7), the cs35l41 driver fails to load. If my understanding is correct, this will prevent code in the patch to be executed, even if some code paths in cs35l41 are bypassed by the patch, right? Please correct me if I'm wrong, as really I'm a newbie in this area.

I'm 100% sure that the patch is applied though, but I don't see the related printk in the kernel log (in particular there is no "CSC3551: probing"). What I am trying to understand is whether this is because of the cs35l41 error, and in which case I should look into this issue first, or whether this is due to another problem.

While unloading and reloading cs35l41 modules (snd_hda_scodec_cs35l41_i2c snd_hda_scodec_cs35l41_spi snd_hda_scodec_cs35l41 snd_soc_cs35l41_lib snd_hda_cs_dsp_ctls cs_dsp), there's no indication of the driver being initialized again in kernel logs, so my guess is that this is triggered by another sound module. Would you have any hint on a what should be done to unload/reload the sound subsystem and avoid reboot between each code modification/build?

Thank you so far for the help and the patches. Even if I cannot ever hear sound from the speakers (and I can perfectly live with this), your work is really appreciated!

(In reply to Cameron Berkenpas from comment #742)
> You have the slim? I don't think I added slim support to the patch. I think
> someone else did and it worked.
>
> It's not that hard to do. The numeric ID you need can be found in your
> alsa-info.