Hi, sorry for jumping into your discussion but I am trying to summarize them to make sure we are on the same page. Pardon me to manually copy-and-paste partial sentences to quote.
ACK: - Don't expose DAI connections in compatible strings. - Use "model" DT property to make the card more UCM2-friendly. - Expose new DT properties to distinguish different DMIC models.
NACK: - All the board variations using exactly the same compatible string. => This is less realistic. Although the CODECS information can be retrieved from DT, it is inevitable to have some custom code for each CODEC.
Per Mark's words:
a different CODEC is something that often justifies a separate compatible
I think we should use different compatible strings for new CODECS combinations. And we should try to reuse the machine driver if they share the most code. In the worst case, introduce a new machine driver for the new CODECS combinations.
- Srinivas's suggestion to set driver_name. e.g. card->driver_name = "SM8250"; => This sounds like a new DT property should be parsed in sound/soc/qcom/common.c. For example: "qcom,family"? But as we do less care about UCM2 for now, I would prefer to just leave it as is.
I would expect the following variants in DTS (just for example):
sound { compatible = "qcom,sc7180-trogdor"; model = "sc7180-rt5682-max98357a-1mic"; }
sound { compatible = "qcom,sc7180-trogdor"; model = "sc7180-rt5682-max98357a-2mic"; dmic-gpio = ... }
sound { compatible = "qcom,sc7180-pompom"; model = "sc7180-adau7002-max98357a"; }
Please correct me if there is any misunderstanding.