On 12/06/2024 11:19, Mark Brown wrote:
On Wed, Jun 12, 2024 at 10:19:06AM +0100, Richard Fitzgerald wrote:
On 11/06/2024 17:12, Mark Brown wrote:
This doesn't seem particularly different to any other unhelpful chip default, I'm not sure why it'd be so urgent that we'd hard code a
I'm not sure I understand the objection here. Are you objecting to the patch itself, or that I marked it as a Fixes?
Both I guess, but mainly the patch itself - we generally have an extremely high bar for setting defaults different to the chip defaults to avoid issues with differing use cases.
But that's somewhat part of the problem. There's no such thing as a chip default for the cs35l56 because for Windows reasons the firmware patches up all the registers on boot to setup a hardcoded use-case configuration so that the Windows SDCA drivers can be generic and don't need knowledge of chip-specific registers. The firmware is customized per end-product, so the initial register state can vary.
The driver currently attempts to sync-up the mixer registers with what the firmware set them to, which means that the initial starting state of the ALSA controls can vary between products using the cs35l56, and in theory even between revisions of the firmware if there was a need to change the routing setup for Windows. We don't really need to do that on Linux - it has a use-case manager and ALSA controls for this stuff, and the code to do all the syncing-up adds a lot of driver complexity. We want to remove that complexity, and instead patch the registers back to silicon defaults - obliterate the Windows use-case setup and use standard Linux mechanisms to setup what is required.
However, the mixer settings were already causing a bunch of log warnings. So I decided to split this fix off so it's not dependent on a big code revert.
I can send a V2 of this patch with this long explanation of the background. I didn't put it all in V1 because it never occurred to me that defaulting the mixer sources would be controversial.