I don't understand what "logic scattered in various dtsi files" means,
sorry.
Yes, that should work to describe the dailink we are using....
But a more tricky issue is how to do calls like setting PLL in dai startup ops.
I think that asking a generic machine driver to do configuration likeRichard was looking at some basic configuration for PLLs.
this with only a limited interface of device property
might be too much of an ask for the machine driver.
Would you mind if I simplify the compatible string like SrinivasThe CODEC change is going to be described in the DT no matter what -
suggested, and send a v12?
As for other two kinds of variations that I am aware of:
1. front mic / rear mic
2. replace alc5682 with adau7002
you'll have a reference to the CODEC node but it may make sense if
there's enough custom code around it. For front vs rear mic the
simplest thing would just be to not mention which if this is a hardware
fixed thing, otherwise a control.
We can set different board names and different compatible strings toI don't recall having suggested distinguishing these things with a
achieve such variation.
So that it would make sense to describe configuration in compatible
strings like you suggested, and also provides UCM a way to distinguish
different boards.
compatible string, especially not the microphones. UCM can already use
the display names for the boards to distinguish things.