| Message ID | 20200914080619.4178587-3-cychiang@chromium.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add documentation and machine driver for SC7180 sound card | expand |
On Mon, 14 Sep 2020 16:06:18 +0800, Cheng-Yi Chiang wrote: > Add devicetree bindings documentation file for sc7180 sound card. > > Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org> > --- > .../bindings/sound/qcom,sc7180.yaml | 130 ++++++++++++++++++ > 1 file changed, 130 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sound/qcom,sc7180.yaml > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed.
On Tue, Sep 15, 2020 at 1:48 AM Rob Herring <robh@kernel.org> wrote: > > On Mon, 14 Sep 2020 16:06:18 +0800, Cheng-Yi Chiang wrote: > > Add devicetree bindings documentation file for sc7180 sound card. > > > > Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org> > > --- > > .../bindings/sound/qcom,sc7180.yaml | 130 ++++++++++++++++++ > > 1 file changed, 130 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/sound/qcom,sc7180.yaml > > > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > there's no need to repost patches *only* to add the tags. The upstream > maintainer will do that for acks received on the version they apply. > > If a tag was not added on purpose, please state why and what changed. > Hi Rob, There was a change between v9 and v10 on compatible string so I did not add your Reviewed-by. Now it is "qcom,sc7180-sndcard-rt5682-m98357-1mic" following Stephan's comment in https://patchwork.kernel.org/comment/23608881/ to make compatible string more specific to board configuration. I only add the note to the cover letter. Sorry the cover letter became too long to follow. I will add the note in patch mail itself for future changes. Thanks for taking a look again.
On Tue, Sep 15, 2020 at 8:44 PM Cheng-yi Chiang <cychiang@chromium.org> wrote: > > On Tue, Sep 15, 2020 at 1:48 AM Rob Herring <robh@kernel.org> wrote: > > > > On Mon, 14 Sep 2020 16:06:18 +0800, Cheng-Yi Chiang wrote: > > > Add devicetree bindings documentation file for sc7180 sound card. > > > > > > Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org> > > > --- > > > .../bindings/sound/qcom,sc7180.yaml | 130 ++++++++++++++++++ > > > 1 file changed, 130 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/sound/qcom,sc7180.yaml > > > > > > > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > > there's no need to repost patches *only* to add the tags. The upstream > > maintainer will do that for acks received on the version they apply. > > > > If a tag was not added on purpose, please state why and what changed. > > > > Hi Rob, > There was a change between v9 and v10 on compatible string so I did > not add your Reviewed-by. > Now it is "qcom,sc7180-sndcard-rt5682-m98357-1mic" following Stephan's > comment in > > https://patchwork.kernel.org/comment/23608881/ > > to make compatible string more specific to board configuration. > I only add the note to the cover letter. Sorry the cover letter became > too long to follow. > I will add the note in patch mail itself for future changes. > Thanks for taking a look again. Hi Rob, Could you please kindly review this patch ? v11 contains the compatible string "qcom,sc7180-sndcard-rt5682-m98357-1mic" following Stephan's suggestion in "[v9,3/3] ASoC: qcom: sc7180: Add machine driver for sound card registration" ( https://patchwork.kernel.org/patch/11770201/#23608881 ) to specify the combination of components. Please let me know if this looks good to you. Thanks!
Hi Cheng, Sorry for such late review w.r.t compatibles, 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@codeaurora.org> > + - Cheng-Yi Chiang<cychiang@chromium.org> > + > +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? 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? 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! Thanks, srini
On Tue, Oct 13, 2020 at 6:36 PM Srinivas Kandagatla <srinivas.kandagatla@linaro.org> 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@codeaurora.org> > > + - Cheng-Yi Chiang<cychiang@chromium.org> > > + > > +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
On Thu, Oct 15, 2020 at 03:59:26PM +0800, Cheng-yi Chiang wrote: > On Tue, Oct 13, 2020 at 6:36 PM Srinivas Kandagatla > > > +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. That sounds like something that could be better described with properties (including for example the existing bindings used for setting up things like analogue outputs and DAPM routes)? > 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. These feel more like things that fit with compatible, though please take a look at Morimoto-san's (CCed) work on generic sound cards for more complex devices: https://lore.kernel.org/alsa-devel/87imbeybq5.wl-kuninori.morimoto.gx@renesas.com/ This is not yet implemented but it'd be good to make sure that the Qualcomm systems can be handled too in future. > 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. OTOH if you have lots of compatibles then it can get hard to work out exactly which one corresponds to a given board.
On Fri, Oct 16, 2020 at 12:13 AM Mark Brown <broonie@kernel.org> wrote: > > On Thu, Oct 15, 2020 at 03:59:26PM +0800, Cheng-yi Chiang wrote: > > On Tue, Oct 13, 2020 at 6:36 PM Srinivas Kandagatla > > > > > +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. > > That sounds like something that could be better described with > properties (including for example the existing bindings used for setting > up things like analogue outputs and DAPM routes)? > Hi Mark, thank you for the comments. May I know your suggestion on Ajye's patch "ASoC: qcom: sc7180: Modify machine driver for 2mic" ? https://lore.kernel.org/r/20200928063744.525700-3-ajye_huang@compal.corp-partner.google.com I think adding code in the machine driver makes the intent straightforward. If we want the machine driver to be fully configurable, we can always add more code to handle properties like gpio, route, widget (mux, text selection) passed in from the device tree. But I feel that we don't need a machine driver to be that configurable from the device tree. I think having the logic scattered in various dtsi files and relying on manual inspection to understand the usage would be less maintainable than only exposing needed property like gpio. Especially in the complicated case where we need to create a mux widget with callback toggling the gpio like this: +static const char * const dmic_mux_text[] = { + "Front Mic", + "Rear Mic", +}; + +static SOC_ENUM_SINGLE_DECL(sc7180_dmic_enum, + SND_SOC_NOPM, 0, dmic_mux_text); + +static const struct snd_kcontrol_new sc7180_dmic_mux_control = + SOC_DAPM_ENUM_EXT("DMIC Select Mux", sc7180_dmic_enum, + dmic_get, dmic_set); + +SND_SOC_DAPM_MUX("Dmic Mux", SND_SOC_NOPM, 0, 0, &sc7180_dmic_mux_control), Passing all the logic along with the callback of dmic_get, dmic_set from the device tree would be too hard to maintain. > > 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. > > These feel more like things that fit with compatible, though please take > a look at Morimoto-san's (CCed) work on generic sound cards for more > complex devices: > > https://lore.kernel.org/alsa-devel/87imbeybq5.wl-kuninori.morimoto.gx@renesas.com/ > > This is not yet implemented but it'd be good to make sure that the > Qualcomm systems can be handled too in future. 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. /* Configure PLL1 for codec */ ret = snd_soc_dai_set_pll(codec_dai, 0, RT5682_PLL1_S_MCLK, DEFAULT_MCLK_RATE, RT5682_PLL1_FREQ); 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. > > > 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. > > OTOH if you have lots of compatibles then it can get hard to work out > exactly which one corresponds to a given board. Totally agree. Glad we have only three variations up to now. 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 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. What do you think ? Thanks!
On Tue, Oct 20, 2020 at 09:37:05PM +0800, Cheng-yi Chiang wrote: > May I know your suggestion on Ajye's patch "ASoC: qcom: sc7180: Modify > machine driver for 2mic" ? > https://lore.kernel.org/r/20200928063744.525700-3-ajye_huang@compal.corp-partner.google.com > I think adding code in the machine driver makes the intent straightforward. > If we want the machine driver to be fully configurable, > we can always add more code to handle properties like gpio, route, > widget (mux, text selection) passed in from the device tree. If the device has both front and rear mics and only one can be active at once that seems obvious and sensible. If the devices only have one of these then this seems like a bad idea. > But I feel that we don't need a machine driver to be that configurable > from the device tree. > I think having the logic scattered in various dtsi files and relying > on manual inspection to understand the usage would be less > maintainable than only exposing needed property like gpio. > Especially in the complicated case where we need to create a mux > widget with callback toggling the gpio like this: 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.
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
On Tue, Oct 20, 2020 at 10:37 PM Mark Brown <broonie@kernel.org> wrote: > > On Tue, Oct 20, 2020 at 09:37:05PM +0800, Cheng-yi Chiang wrote: > > > May I know your suggestion on Ajye's patch "ASoC: qcom: sc7180: Modify > > machine driver for 2mic" ? > > > https://lore.kernel.org/r/20200928063744.525700-3-ajye_huang@compal.corp-partner.google.com > > > I think adding code in the machine driver makes the intent straightforward. > > If we want the machine driver to be fully configurable, > > we can always add more code to handle properties like gpio, route, > > widget (mux, text selection) passed in from the device tree. > > If the device has both front and rear mics and only one can be active at > once that seems obvious and sensible. If the devices only have one of > these then this seems like a bad idea. > trogdor board: only front mic. pompom board: having both front mic and rear mic. Only one of them will be used at a time. It is toggled by mixer control backed by a gpio. My proposed solution: instead of using compatible strings, expose only dmic-gpio property. When the machine driver sees this property, it uses the dapm widgets and controls created in the machine driver. > > But I feel that we don't need a machine driver to be that configurable > > from the device tree. > > I think having the logic scattered in various dtsi files and relying > > on manual inspection to understand the usage would be less > > maintainable than only exposing needed property like gpio. > > Especially in the complicated case where we need to create a mux > > widget with callback toggling the gpio like this: > > I don't understand what "logic scattered in various dtsi files" means, > sorry. > I mean I don't want to use device property to pass in widget name, type, text and callbacks. Let me give an example: - Board trogdor uses front mic, rt5682, and max98357a. - Board pompom is based on board trogdor, but it has front mic and rear mic. If we somehow managed to add the code to pass in widget, route, type, text, and callbacks needed for dmic control, we will need to put a bunch of properties in trogdor-pompom.dtsi file. - Board ABC is based on trogdor as well, and it has front mic and rear mic, but with a different speaker amp. To use widget, route, type, text and callbacks for front mic and rear mic, in trogdor-ABC.dtsi file we would copy some properties used in trogdor-pompom.dtsi file. To support the different combination of codec, we would need some modification of the route and widget. Now the support of front mic and rear mic switch is scattered in trogdor-ABC.dtsi and trogdor-pompom.dtsi files. For example, when we change the code to parse or build the widget and route, we need to fix both trogdor-pompom.dtsi and trogdor-ABC.dtsi. Alternatively, if we only expose dmic-gpio property and put surrounding code in the machine driver, we can use this dmic-gpio property, plus the sound card name to identify the needed widget and route. > > 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. That sounds promising. If we don't need to include the codec driver header file explicitly, that can make machine drivers simpler. Maybe for most of the simple cases we don't even need a dedicated machine driver. > > > 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. > Would you suggest checking whether the codec node is a rt5682 node, and call required PLL calls accordingly ? "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." Sorry I am not sure if I understand this correctly. Please correct me if I am wrong. - For default case having 1 mic: not mention this at all - For front mic / rear mic case: see gpio property and use an additional 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. My apology that I made the wrong interpretation when I read your reply "These feel more like things that fit with compatible" regarding replacing alc5682 with adau7002. Please let me know which one solution you prefer: - deriving this information from codec node - deriving this information from different sound card name Thanks so much!
On Tue, Oct 20, 2020 at 10:55 PM Srinivas Kandagatla <srinivas.kandagatla@linaro.org> 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!
On Wed, Oct 21, 2020 at 02:51:33AM +0800, Cheng-yi Chiang wrote: > On Tue, Oct 20, 2020 at 10:37 PM Mark Brown <broonie@kernel.org> wrote: > > If the device has both front and rear mics and only one can be active at > > once that seems obvious and sensible. If the devices only have one of > > these then this seems like a bad idea. > trogdor board: only front mic. > pompom board: having both front mic and rear mic. Only one of them > will be used at a time. It is toggled by mixer control backed by a > gpio. > My proposed solution: instead of using compatible strings, expose only > dmic-gpio property. > When the machine driver sees this property, it uses the dapm widgets > and controls created in the machine driver. Yes, that is what I would expect. > > I don't understand what "logic scattered in various dtsi files" means, > > sorry. > I mean I don't want to use device property to pass in widget name, > type, text and callbacks. > Let me give an example: > - Board trogdor uses front mic, rt5682, and max98357a. > - Board pompom is based on board trogdor, but it has front mic and rear mic. > If we somehow managed to add the code to pass in widget, route, type, > text, and callbacks needed for dmic control, we will need to put a > bunch of properties in trogdor-pompom.dtsi file. Most of this code is already there as part of the generic card infrastructure, the only thing that stands out for me is the GPIO to switch between the front and rear mics. > - Board ABC is based on trogdor as well, and it has front mic and rear > mic, but with a different speaker amp. > To use widget, route, type, text and callbacks for front mic and rear > mic, in trogdor-ABC.dtsi file we would copy some properties used in > trogdor-pompom.dtsi file. To support the different combination of > codec, we would need some modification of the route and widget. It shouldn't be hugely difficult to split the DT files up usually, and ideally they'd be small enough that just having an entirely new sound bit isn't the end of the world. Again I'm just not clear what you're seeing here. > > 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. > Would you suggest checking whether the codec node is a rt5682 node, > and call required PLL calls accordingly ? Potentially, or there might be so little shared that it's just a separate machine driver. > "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." > Sorry I am not sure if I understand this correctly. Please correct me > if I am wrong. > - For default case having 1 mic: not mention this at all > - For front mic / rear mic case: see gpio property and use an > additional control. Yes. > "These feel more like things that fit with compatible" regarding > replacing alc5682 with adau7002. Please let me know which one solution > you prefer: > - deriving this information from codec node > - deriving this information from different sound card name To an extent this depends on how different the CODECs and general setup are but a different CODEC is something that often justifies a separate compatible. Of course you also have an awful lot of systems that work with the generic card drivers and all different kinds of CPU and CODEC, usually because the driver doesn't need to know anything about the implementation of either.
On 20/10/2020 19:54, Cheng-yi Chiang wrote: >> 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 ? For example if we set below property for sound card in Device tree model = "RB5"; We will end up with # cat /proc/asound/cards 0 [RB5 ]: RB5 - RB5 RB5 This is totally not very useful w.r.t UCM2 and makes it very difficult to common up parts of the configs. My suggestions are. 1. set card->driver_name to something more sensible in your sound card driver. ex: card->driver_name = "SM8250"; 2. set long name in model DT property and set it as card long name ex: in DT: model = "Qualcomm-RB5-WSA8815-Speakers-DMIC0"; in sound driver or common.c: of_property_read_string_index(np, "model", 0, &card->long_name); With this set: now # cat /proc/asound/cards 0 [QualcommRB5WSA8]: SM8250 - Qualcomm-RB5-WSA8815-Speakers-D Qualcomm-RB5-WSA8815-Speakers-DMIC0 This also means that in UCM2 we can have a top level SM8250 directory which can contain other board variants something like: ucm2/Qualcomm/sm8250/Qualcomm-RB5-WSA8815-Speakers-DMIC0.conf ucm2/Qualcomm/sm8250/Qualcomm-RB5-WSA8810-Speakers-DMIC123.conf and so on! Finally Only comment I had regarding compatible was not to encapsulate the connection details in it!. these can be made more sensible, something like "qcom,sc7180-trogdor-v1", "qcom,sc7180-trogdor-v2".. and so on. This compatible has nothing to do with driver or card short and long name. Does that makes sense? Thanks, srini with Currently if
On Wed, Oct 21, 2020 at 01:00:54PM +0100, Srinivas Kandagatla wrote: > This is totally not very useful w.r.t UCM2 and makes it very difficult to > common up parts of the configs. > My suggestions are. > 1. set card->driver_name to something more sensible in your sound card > driver. > 2. set long name in model DT property and set it as card long name It's also worth taking a look at what Intel are doing here with their cards.
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.
On 22/10/2020 04:29, Tzung-Bi Shih wrote: > 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. > No, you can just hardcode this driver_name in your machine driver rather than getting it from DT, this is how everyone does!. So need of adding anything to common.c The thing that I suggested to add to common.c is setting card->long_name from "model" property. > > I would expect the following variants in DTS (just for example): > > sound { > compatible = "qcom,sc7180-trogdor"; Make sure that vendor name is correct here, am not sure if trogdor is qcom board or Google own board! > 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. Looks good to me! thanks for doing this! --srini >
Sorry for resending this mail. I forgot to use plain text mode in the previous mail. On Thu, Oct 22, 2020 at 6:12 PM Srinivas Kandagatla <srinivas.kandagatla@linaro.org> wrote: > > > > On 22/10/2020 04:29, Tzung-Bi Shih wrote: > > 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. > > > No, you can just hardcode this driver_name in your machine driver rather > than getting it from DT, this is how everyone does!. > So need of adding anything to common.c > ACK > The thing that I suggested to add to common.c is setting card->long_name > from "model" property. > NACK I found that I don't need to set card->long_name in common.c because soc-core.c already sets longname using card->name if card->long_name is NULL. soc_setup_card_name(card->snd_card->longname, card->long_name, card->name, 0); So we can leave common.c as it is and still get long name. > > > > I would expect the following variants in DTS (just for example): > > > > sound { > > compatible = "qcom,sc7180-trogdor"; > Make sure that vendor name is correct here, am not sure if trogdor is > qcom board or Google own board! ACK I should use "google,sc7180-trogdor" because google is the vendor. > > > 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. > > Looks good to me! > thanks for doing this! Thank you. I will collect the discussion result to send a v12, and sync with variant board partners to submit following machine driver changes. We will make sure future projects follow this approach > > --srini > >
diff --git a/Documentation/devicetree/bindings/sound/qcom,sc7180.yaml b/Documentation/devicetree/bindings/sound/qcom,sc7180.yaml new file mode 100644 index 000000000000..b77311bb5190 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,sc7180.yaml @@ -0,0 +1,130 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$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@codeaurora.org> + - Cheng-Yi Chiang <cychiang@chromium.org> + +description: + This binding describes the SC7180 sound card which uses LPASS for audio. + +properties: + compatible: + const: qcom,sc7180-sndcard-rt5682-m98357-1mic + + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^dai-link(@[0-9])?$": + description: + Each subnode represents a dai link. Subnodes of each dai links would be + cpu/codec dais. + + type: object + + properties: + link-name: + description: Indicates dai-link name and PCM stream name. + $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 + + reg: + description: dai link address. + + cpu: + description: Holds subnode which indicates cpu dai. + type: object + properties: + sound-dai: true + + codec: + description: Holds subnode which indicates codec dai. + type: object + properties: + sound-dai: true + + required: + - link-name + - cpu + - codec + + additionalProperties: false + +required: + - compatible + - model + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + + - | + sound { + compatible = "qcom,sc7180-sndcard-rt5682-m98357-1mic"; + model = "sc7180-snd-card"; + + audio-routing = + "Headphone Jack", "HPOL", + "Headphone Jack", "HPOR"; + + #address-cells = <1>; + #size-cells = <0>; + + dai-link@0 { + link-name = "MultiMedia0"; + reg = <0>; + cpu { + sound-dai = <&lpass_cpu 0>; + }; + + codec { + sound-dai = <&alc5682 0>; + }; + }; + + dai-link@1 { + link-name = "MultiMedia1"; + reg = <1>; + cpu { + sound-dai = <&lpass_cpu 1>; + }; + + codec { + sound-dai = <&max98357a>; + }; + }; + + dai-link@2 { + link-name = "MultiMedia2"; + reg = <2>; + cpu { + sound-dai = <&lpass_hdmi 0>; + }; + + codec { + sound-dai = <&msm_dp>; + }; + }; + };
Add devicetree bindings documentation file for sc7180 sound card. Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org> --- .../bindings/sound/qcom,sc7180.yaml | 130 ++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/qcom,sc7180.yaml