On Tue, Oct 20, 2020 at 10:55 PM Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> wrote: > > > > On 20/10/2020 15:37, Mark Brown wrote: > > 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 like > >> this with only a limited interface of device property > >> might be too much of an ask for the machine driver. > > Richard was looking at some basic configuration for PLLs. > > > >> Would you mind if I simplify the compatible string like Srinivas > >> 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 > > The CODEC change is going to be described in the DT no matter what - > > 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 to > >> 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. > > I don't recall having suggested distinguishing these things with a > > compatible string, especially not the microphones. UCM can already use > > the display names for the boards to distinguish things. > > > Not with the compatible string! > > Currently card name, and long name are exactly same in all Qualcomm > soundcards, which makes it very difficult to identify how those boards > re wired up at UCM2 level. So the plan is to properly populate card long > name with "model" property which can include details on how things are > wiredup on that board. > > --srini Hi Srini, Thanks for taking a look. Let me try to clarify your comments in case there is any misunderstanding. I understand your request on having different board variations using different sound card names through model property, and I totally agree with that. As for compatible strings, do you insist on having all the board variations using exactly the same compatible string ? Thanks!
