All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cheng-yi Chiang <cychiang@chromium.org>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Tzung-Bi Shih <tzungbi@google.com>,
	Mark Brown <broonie@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Taniya Das <tdas@codeaurora.org>,
	Rohit kumar <rohitkr@codeaurora.org>,
	Banajit Goswami <bgoswami@codeaurora.org>,
	Patrick Lai <plai@codeaurora.org>, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Stephan Gerhold <stephan@gerhold.net>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Srinivasa Rao <srivasam@codeaurora.org>,
	Doug Anderson <dianders@chromium.org>,
	Dylan Reid <dgreid@chromium.org>,
	Tzung-Bi Shih <tzungbi@chromium.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	"moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM..."  <alsa-devel@alsa-project.org>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Ajye Huang <ajye_huang@compal.corp-partner.google.com>,
	xuyuqing@huaqin.corp-partner.google.com
Subject: Re: [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings
Date: Fri, 23 Oct 2020 15:55:35 +0800	[thread overview]
Message-ID: <CAFv8Nw+zigiF0cbuk8t+4inf_X6twh+2zyyXchRTXASM4V_xBQ@mail.gmail.com> (raw)
In-Reply-To: <14e7db29-4825-6e9d-22a0-5121bb7006e2@linaro.org>

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
> >

WARNING: multiple messages have this Message-ID (diff)
From: Cheng-yi Chiang <cychiang@chromium.org>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Taniya Das <tdas@codeaurora.org>,
	"moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM..." <alsa-devel@alsa-project.org>,
	Banajit Goswami <bgoswami@codeaurora.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Takashi Iwai <tiwai@suse.com>,
	Rohit kumar <rohitkr@codeaurora.org>,
	Ajye Huang <ajye_huang@compal.corp-partner.google.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Patrick Lai <plai@codeaurora.org>,
	Tzung-Bi Shih <tzungbi@google.com>,
	Andy Gross <agross@kernel.org>, Dylan Reid <dgreid@chromium.org>,
	Jaroslav Kysela <perex@perex.cz>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Tzung-Bi Shih <tzungbi@chromium.org>,
	Srinivasa Rao <srivasam@codeaurora.org>,
	Stephan Gerhold <stephan@gerhold.net>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Doug Anderson <dianders@chromium.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	xuyuqing@huaqin.corp-partner.google.com,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings
Date: Fri, 23 Oct 2020 15:55:35 +0800	[thread overview]
Message-ID: <CAFv8Nw+zigiF0cbuk8t+4inf_X6twh+2zyyXchRTXASM4V_xBQ@mail.gmail.com> (raw)
In-Reply-To: <14e7db29-4825-6e9d-22a0-5121bb7006e2@linaro.org>

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
> >

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Cheng-yi Chiang <cychiang@chromium.org>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Taniya Das <tdas@codeaurora.org>,
	"moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM..." <alsa-devel@alsa-project.org>,
	Banajit Goswami <bgoswami@codeaurora.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Takashi Iwai <tiwai@suse.com>,
	Rohit kumar <rohitkr@codeaurora.org>,
	Ajye Huang <ajye_huang@compal.corp-partner.google.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Patrick Lai <plai@codeaurora.org>,
	Tzung-Bi Shih <tzungbi@google.com>,
	Andy Gross <agross@kernel.org>, Dylan Reid <dgreid@chromium.org>,
	Jaroslav Kysela <perex@perex.cz>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Tzung-Bi Shih <tzungbi@chromium.org>,
	Srinivasa Rao <srivasam@codeaurora.org>,
	Stephan Gerhold <stephan@gerhold.net>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Doug Anderson <dianders@chromium.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	xuyuqing@huaqin.corp-partner.google.com,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings
Date: Fri, 23 Oct 2020 15:55:35 +0800	[thread overview]
Message-ID: <CAFv8Nw+zigiF0cbuk8t+4inf_X6twh+2zyyXchRTXASM4V_xBQ@mail.gmail.com> (raw)
In-Reply-To: <14e7db29-4825-6e9d-22a0-5121bb7006e2@linaro.org>

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
> >

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Cheng-yi Chiang <cychiang@chromium.org>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Taniya Das <tdas@codeaurora.org>,
	"moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM..." <alsa-devel@alsa-project.org>,
	Banajit Goswami <bgoswami@codeaurora.org>,
	Heiko Stuebner <heiko@sntech.de>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Takashi Iwai <tiwai@suse.com>,
	Rohit kumar <rohitkr@codeaurora.org>,
	Ajye Huang <ajye_huang@compal.corp-partner.google.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Patrick Lai <plai@codeaurora.org>,
	Tzung-Bi Shih <tzungbi@google.com>,
	Andy Gross <agross@kernel.org>, Dylan Reid <dgreid@chromium.org>,
	Jaroslav Kysela <perex@perex.cz>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Tzung-Bi Shih <tzungbi@chromium.org>,
	Srinivasa Rao <srivasam@codeaurora.org>,
	Stephan Gerhold <stephan@gerhold.net>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Doug Anderson <dianders@chromium.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	xuyuqing@huaqin.corp-partner.google.com,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings
Date: Fri, 23 Oct 2020 15:55:35 +0800	[thread overview]
Message-ID: <CAFv8Nw+zigiF0cbuk8t+4inf_X6twh+2zyyXchRTXASM4V_xBQ@mail.gmail.com> (raw)
In-Reply-To: <14e7db29-4825-6e9d-22a0-5121bb7006e2@linaro.org>

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
> >

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-10-23  7:56 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14  8:06 [PATCH v11 0/3] Add documentation and machine driver for SC7180 sound card Cheng-Yi Chiang
2020-09-14  8:06 ` Cheng-Yi Chiang
2020-09-14  8:06 ` Cheng-Yi Chiang
2020-09-14  8:06 ` Cheng-Yi Chiang
2020-09-14  8:06 ` Cheng-Yi Chiang
2020-09-14  8:06 ` [PATCH v11 1/3] ASoC: hdmi-codec: Use set_jack ops to set jack Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14  8:06 ` [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14 17:48   ` Rob Herring
2020-09-14 17:48     ` Rob Herring
2020-09-14 17:48     ` Rob Herring
2020-09-14 17:48     ` Rob Herring
2020-09-14 17:48     ` Rob Herring
2020-09-15 12:44     ` Cheng-yi Chiang
2020-09-15 12:44       ` Cheng-yi Chiang
2020-09-15 12:44       ` Cheng-yi Chiang
2020-09-15 12:44       ` Cheng-yi Chiang
2020-09-15 12:44       ` Cheng-yi Chiang
2020-10-13  3:46       ` Cheng-yi Chiang
2020-10-13  3:46         ` Cheng-yi Chiang
2020-10-13  3:46         ` Cheng-yi Chiang
2020-10-13  3:46         ` Cheng-yi Chiang
2020-10-13  3:46         ` Cheng-yi Chiang
2020-10-13 10:36   ` Srinivas Kandagatla
2020-10-13 10:36     ` Srinivas Kandagatla
2020-10-13 10:36     ` Srinivas Kandagatla
2020-10-13 10:36     ` Srinivas Kandagatla
2020-10-13 10:36     ` Srinivas Kandagatla
2020-10-15  7:59     ` Cheng-yi Chiang
2020-10-15  7:59       ` Cheng-yi Chiang
2020-10-15  7:59       ` Cheng-yi Chiang
2020-10-15  7:59       ` Cheng-yi Chiang
2020-10-15  7:59       ` Cheng-yi Chiang
2020-10-15 16:12       ` Mark Brown
2020-10-15 16:12         ` Mark Brown
2020-10-15 16:12         ` Mark Brown
2020-10-15 16:12         ` Mark Brown
2020-10-15 16:12         ` Mark Brown
2020-10-20 13:37         ` Cheng-yi Chiang
2020-10-20 13:37           ` Cheng-yi Chiang
2020-10-20 13:37           ` Cheng-yi Chiang
2020-10-20 13:37           ` Cheng-yi Chiang
2020-10-20 13:37           ` Cheng-yi Chiang
2020-10-20 14:37           ` Mark Brown
2020-10-20 14:37             ` Mark Brown
2020-10-20 14:37             ` Mark Brown
2020-10-20 14:37             ` Mark Brown
2020-10-20 14:37             ` Mark Brown
2020-10-20 14:55             ` Srinivas Kandagatla
2020-10-20 14:55               ` Srinivas Kandagatla
2020-10-20 14:55               ` Srinivas Kandagatla
2020-10-20 14:55               ` Srinivas Kandagatla
2020-10-20 14:55               ` Srinivas Kandagatla
2020-10-20 18:54               ` Cheng-yi Chiang
2020-10-20 18:54                 ` Cheng-yi Chiang
2020-10-20 18:54                 ` Cheng-yi Chiang
2020-10-20 18:54                 ` Cheng-yi Chiang
2020-10-20 18:54                 ` Cheng-yi Chiang
2020-10-21 12:00                 ` Srinivas Kandagatla
2020-10-21 12:00                   ` Srinivas Kandagatla
2020-10-21 12:00                   ` Srinivas Kandagatla
2020-10-21 12:00                   ` Srinivas Kandagatla
2020-10-21 12:00                   ` Srinivas Kandagatla
2020-10-21 12:39                   ` Mark Brown
2020-10-21 12:39                     ` Mark Brown
2020-10-21 12:39                     ` Mark Brown
2020-10-21 12:39                     ` Mark Brown
2020-10-21 12:39                     ` Mark Brown
2020-10-22  3:29                     ` Tzung-Bi Shih
2020-10-22  3:29                       ` Tzung-Bi Shih
2020-10-22  3:29                       ` Tzung-Bi Shih
2020-10-22  3:29                       ` Tzung-Bi Shih
2020-10-22  3:29                       ` Tzung-Bi Shih
2020-10-22 10:12                       ` Srinivas Kandagatla
2020-10-22 10:12                         ` Srinivas Kandagatla
2020-10-22 10:12                         ` Srinivas Kandagatla
2020-10-22 10:12                         ` Srinivas Kandagatla
2020-10-22 10:12                         ` Srinivas Kandagatla
2020-10-23  7:55                         ` Cheng-yi Chiang [this message]
2020-10-23  7:55                           ` Cheng-yi Chiang
2020-10-23  7:55                           ` Cheng-yi Chiang
2020-10-23  7:55                           ` Cheng-yi Chiang
2020-10-20 18:51             ` Cheng-yi Chiang
2020-10-20 18:51               ` Cheng-yi Chiang
2020-10-20 18:51               ` Cheng-yi Chiang
2020-10-20 18:51               ` Cheng-yi Chiang
2020-10-20 18:51               ` Cheng-yi Chiang
2020-10-20 19:39               ` Mark Brown
2020-10-20 19:39                 ` Mark Brown
2020-10-20 19:39                 ` Mark Brown
2020-10-20 19:39                 ` Mark Brown
2020-10-20 19:39                 ` Mark Brown
2020-09-14  8:06 ` [PATCH v11 3/3] ASoC: qcom: sc7180: Add machine driver for sound card registration Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-09-14  8:06   ` Cheng-Yi Chiang
2020-10-13  3:50   ` Cheng-yi Chiang
2020-10-13  3:50     ` Cheng-yi Chiang
2020-10-13  3:50     ` Cheng-yi Chiang
2020-10-13  3:50     ` Cheng-yi Chiang
2020-10-13  3:50     ` Cheng-yi Chiang
2020-10-15  8:02     ` Cheng-yi Chiang
2020-10-15  8:02       ` Cheng-yi Chiang
2020-10-15  8:02       ` Cheng-yi Chiang
2020-10-15  8:02       ` Cheng-yi Chiang
2020-10-15  8:02       ` Cheng-yi Chiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFv8Nw+zigiF0cbuk8t+4inf_X6twh+2zyyXchRTXASM4V_xBQ@mail.gmail.com \
    --to=cychiang@chromium.org \
    --cc=agross@kernel.org \
    --cc=ajye_huang@compal.corp-partner.google.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=bgoswami@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dgreid@chromium.org \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=perex@perex.cz \
    --cc=plai@codeaurora.org \
    --cc=robh+dt@kernel.org \
    --cc=rohitkr@codeaurora.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=srivasam@codeaurora.org \
    --cc=stephan@gerhold.net \
    --cc=tdas@codeaurora.org \
    --cc=tiwai@suse.com \
    --cc=tzungbi@chromium.org \
    --cc=tzungbi@google.com \
    --cc=xuyuqing@huaqin.corp-partner.google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.