On Tue, Oct 13, 2020 at 6:36 PM Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> wrote: > > Hi Cheng, > > Sorry for such late review w.r.t compatibles, > Hi Srini, Thank you for taking another look! > On 14/09/2020 09:06, Cheng-Yi Chiang wrote: > > +--- > > +$id:http://devicetree.org/schemas/sound/qcom,sc7180.yaml# > > +$schema:http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Qualcomm Technologies Inc. SC7180 ASoC sound card driver > > + > > +maintainers: > > + - Rohit kumar<rohitkr@xxxxxxxxxxxxxx> > > + - Cheng-Yi Chiang<cychiang@xxxxxxxxxxxx> > > + > > +description: > > + This binding describes the SC7180 sound card which uses LPASS for audio. > > + > > +properties: > > + compatible: > > + const: qcom,sc7180-sndcard-rt5682-m98357-1mic > > This information can come from the dai link description itself, why > should compatible string have this information? I think dailink description is not enough to specify everything machine driver needs to know. E.g. there is a variation where there are front mic and rear mic. We need to tell the machine driver about it so it can create proper widget, route, and controls. The codec combination also matters. There will be a variation where rt5682 is replaced with adau7002 for dmic. Although machine driver can derive some information by looking at dailink, I think specifying it explicitly in the compatible string is easier to tell what machine driver should do, e.g. setting PLL related to rt5682 or not. > > Can't we have better compatible string with actual board name or use the > same compatible name as used by other boards? > > > Can you give us some details on the advantages of doing this way? Machine driver can easily tell what is expected when it sees the compatible string (or model property, as you suggested below). E.g. in 1-mic v.s. 2-mic case, the patch by Ajye Huang: "[v1,2/2] ASoC: qcom: sc7180: Modify machine driver for 2mic" You can see widget, route, controls are used according to the configuration. The alternative approach is to check whether "dmic-gpio" property exists to decide adding these stuff or not. But it makes the intent less easier to understand. > > Or am I missing something? > > AFAIU, you should add proper board name / model name to the compatible > string rather than describe how its connected. Connection is already > part of dai link definition. > > On the other hand model property can include variant information. > This can also be used to set card long name which will help in UCM2. > > > The reason I had to bring this up is because the use-space (ucm in this > case) will not be in a position to differentiate between different board > variants to select correct mixer controls, so its going to be a pain! I think your suggestions makes sense since we need to consider UCM. Having the card with the same name doing different things will be confusing to user (and to UCM). I'll follow your suggestion to use the same compatible string, and put the board variation information in card name using model property. Thanks a lot for the great help! > > > > Thanks, > srini
