[PATCH] ASoC: SOF: Remove libraries from topology lookups
From: Curtis Malainey cujomalainey@chromium.org
Default firmware shipped in open source are not licensed for 3P libraries, therefore topologies should not reference them.
If a OS wants to use 3P (that they have licensed) then they should use the appropriate topology override mechanisms.
Fixes: 8a7d5d85ed2161 ("ASoC: SOF: mediatek: mt8195: Add devicetree support to select topologies") Signed-off-by: Curtis Malainey cujomalainey@chromium.org Cc: Wojciech Macek wmacek@google.com --- sound/soc/sof/mediatek/mt8195/mt8195.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/mediatek/mt8195/mt8195.c b/sound/soc/sof/mediatek/mt8195/mt8195.c index 8ee7ee246344c..f143baf75af60 100644 --- a/sound/soc/sof/mediatek/mt8195/mt8195.c +++ b/sound/soc/sof/mediatek/mt8195/mt8195.c @@ -573,7 +573,7 @@ static struct snd_sof_dsp_ops sof_mt8195_ops = { static struct snd_sof_of_mach sof_mt8195_machs[] = { { .compatible = "google,tomato", - .sof_tplg_filename = "sof-mt8195-mt6359-rt1019-rt5682-dts.tplg" + .sof_tplg_filename = "sof-mt8195-mt6359-rt1019-rt5682.tplg" }, { .compatible = "mediatek,mt8195", .sof_tplg_filename = "sof-mt8195.tplg"
Il 18/03/24 19:29, cujomalainey@chromium.org ha scritto:
From: Curtis Malainey cujomalainey@chromium.org
Default firmware shipped in open source are not licensed for 3P libraries, therefore topologies should not reference them.
If a OS wants to use 3P (that they have licensed) then they should use the appropriate topology override mechanisms.
That's ok, but still needs the sof-mt8195-mt6359-rt1019-rt5682.tplg firmware in linux-firmware, or this change breaks sound.
Regards, Angelo
Fixes: 8a7d5d85ed2161 ("ASoC: SOF: mediatek: mt8195: Add devicetree support to select topologies") Signed-off-by: Curtis Malainey cujomalainey@chromium.org Cc: Wojciech Macek wmacek@google.com
sound/soc/sof/mediatek/mt8195/mt8195.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/mediatek/mt8195/mt8195.c b/sound/soc/sof/mediatek/mt8195/mt8195.c index 8ee7ee246344c..f143baf75af60 100644 --- a/sound/soc/sof/mediatek/mt8195/mt8195.c +++ b/sound/soc/sof/mediatek/mt8195/mt8195.c @@ -573,7 +573,7 @@ static struct snd_sof_dsp_ops sof_mt8195_ops = { static struct snd_sof_of_mach sof_mt8195_machs[] = { { .compatible = "google,tomato",
.sof_tplg_filename = "sof-mt8195-mt6359-rt1019-rt5682-dts.tplg"
.sof_tplg_filename = "sof-mt8195-mt6359-rt1019-rt5682.tplg"
On Tue, Mar 19, 2024 at 4:07 AM AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com wrote:
Il 18/03/24 19:29, cujomalainey@chromium.org ha scritto:
From: Curtis Malainey cujomalainey@chromium.org
Default firmware shipped in open source are not licensed for 3P libraries, therefore topologies should not reference them.
If a OS wants to use 3P (that they have licensed) then they should use the appropriate topology override mechanisms.
That's ok, but still needs the sof-mt8195-mt6359-rt1019-rt5682.tplg firmware in linux-firmware, or this change breaks sound.
Regards, Angelo
Got any docs I can refer to? I have never contributed to linux-firmware. If you are willing to send the update on my behalf that would be fine by me as well.
Il 19/03/24 16:51, Curtis Malainey ha scritto:
On Tue, Mar 19, 2024 at 4:07 AM AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com wrote:
Il 18/03/24 19:29, cujomalainey@chromium.org ha scritto:
From: Curtis Malainey cujomalainey@chromium.org
Default firmware shipped in open source are not licensed for 3P libraries, therefore topologies should not reference them.
If a OS wants to use 3P (that they have licensed) then they should use the appropriate topology override mechanisms.
That's ok, but still needs the sof-mt8195-mt6359-rt1019-rt5682.tplg firmware in linux-firmware, or this change breaks sound.
Regards, Angelo
Got any docs I can refer to? I have never contributed to linux-firmware. If you are willing to send the update on my behalf that would be fine by me as well.
There you go: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/...
Anyway, can you please also describe what is the appropriate topology override mechanism in the description of this commit?
Thanks, Angelo
On Wed, Mar 20, 2024 at 2:06 AM AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com wrote:
Il 19/03/24 16:51, Curtis Malainey ha scritto:
On Tue, Mar 19, 2024 at 4:07 AM AngeloGioacchino Del Regno angelogioacchino.delregno@collabora.com wrote:
Il 18/03/24 19:29, cujomalainey@chromium.org ha scritto:
From: Curtis Malainey cujomalainey@chromium.org
Default firmware shipped in open source are not licensed for 3P libraries, therefore topologies should not reference them.
If a OS wants to use 3P (that they have licensed) then they should use the appropriate topology override mechanisms.
That's ok, but still needs the sof-mt8195-mt6359-rt1019-rt5682.tplg firmware in linux-firmware, or this change breaks sound.
Regards, Angelo
Got any docs I can refer to? I have never contributed to linux-firmware. If you are willing to send the update on my behalf that would be fine by me as well.
There you go: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/...
Thanks, I have spotted some other issues with the MTK builds, so I will be following up with them on this to get it updated.
Anyway, can you please also describe what is the appropriate topology override mechanism in the description of this commit?
Yep, as I said to Mark it will be part of v2
Curtis
Thanks, Angelo
On Mon, Mar 18, 2024 at 11:29:54AM -0700, cujomalainey@chromium.org wrote:
If a OS wants to use 3P (that they have licensed) then they should use the appropriate topology override mechanisms.
A user who's bisected a problem to this commit might welcome some pointer to what the appropriate topology override mechanism is.
On Tue, Mar 19, 2024 at 4:39 AM Mark Brown broonie@kernel.org wrote:
On Mon, Mar 18, 2024 at 11:29:54AM -0700, cujomalainey@chromium.org wrote:
If a OS wants to use 3P (that they have licensed) then they should use the appropriate topology override mechanisms.
A user who's bisected a problem to this commit might welcome some pointer to what the appropriate topology override mechanism is.
Ack, will add in V2
participants (4)
-
AngeloGioacchino Del Regno -
cujomalainey＠chromium.org -
Curtis Malainey -
Mark Brown