Message ID | 20230628102621.15016-3-srinivas.kandagatla@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp8825636vqr; Wed, 28 Jun 2023 03:47:27 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7t8FdpWeyaHEty3BBc8uLYtoQmYCg70OIjCzXfvsaLIPUY2DVy1idJWTScxHYHAqqpXlZv X-Received: by 2002:a17:907:6d23:b0:988:6526:beaa with SMTP id sa35-20020a1709076d2300b009886526beaamr28655480ejc.40.1687949246918; Wed, 28 Jun 2023 03:47:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687949246; cv=none; d=google.com; s=arc-20160816; b=aePYe72r2yrsSjYRs83/fCDgk92lq3A8BzZqWWwmcTu+MEhR7Cv2+qVFZi9VKNUel4 UeoZ5mIdH7XVZsEf56ZAmiiZB1FaUfX0pgpc3EbErIOgyS/Y4ETyV7evzvO8qo2WJbUS 4X7S1KuhhQ/25A5sldWFBTPWSmyas+XkpKd6WzJfJ0DKPFLCGbxhOvGvLOs9YuotMbOf ojO6oDYm/C2I6lRKowXRAACufDK5BhtBHmFYxoPqcKxsxzOgWalVs1XAY/AY9S6KoUA8 VZlGcHwDPch/a2qj0B4iDYeVZplwwPAJj9JtsmFjA6iESjXHkT/+NFDrsrJgO87lCDlm KcKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=QndBu+Ea73+5HZm45UHtALLqjv/Bpq0i3QEOMrOjFEA=; fh=ANVQFiC6mDhjeU+YM+r8EhAOx8zfpTZwkKvCCAMPXF8=; b=noAl2IOrww4xDGAjVlmyNbTVGVVDuPxB/SbKmrkO4ANOJy8MOaVpi7AadjTEAHzT+m AuYEiq4CiQOdmN92Gjg4fq0lUAP9MW33KA3MJFp0jT+QleZ8ugYdhvTAeRWu4GdZTG0m WkhTP6BhP2fj/Ea0Zo75S6nOYKz00oXZYbPyokZtRLIr0VVQNvCPnoYtyfeB71yogHnH AVm2xnlLBB9szCZKlfSEeLGhSGZFedzePPbyDEIzt6reHErSLmoXh04WUHT8sOIzreyB 9WQ79MAn3SpfTdpJ/JLbZ+mSceBZrXuQoFHVZMhX9sEbOlFJGRuxIwV54tzIYYtHLkuX y3ow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=xXvqIFxI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u18-20020a17090657d200b0098f99532db7si4248095ejr.673.2023.06.28.03.47.00; Wed, 28 Jun 2023 03:47:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=xXvqIFxI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231453AbjF1K3A (ORCPT <rfc822;adanhawthorn@gmail.com> + 99 others); Wed, 28 Jun 2023 06:29:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229982AbjF1K0m (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 28 Jun 2023 06:26:42 -0400 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00D392D7E for <linux-kernel@vger.kernel.org>; Wed, 28 Jun 2023 03:26:40 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-3fbb40ce844so1804365e9.0 for <linux-kernel@vger.kernel.org>; Wed, 28 Jun 2023 03:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1687947999; x=1690539999; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=QndBu+Ea73+5HZm45UHtALLqjv/Bpq0i3QEOMrOjFEA=; b=xXvqIFxIGebSeM10VHUvp6JelIbH0a8Ghpt64wKknXwMSWL95vKtz40Urf/l2eRZyA cjijU5zSPWNmwFnS43WQxxT2utoqGcRzSyayFdaRLw0YHKXIWNe5nbZlSY5r5IUciEtW Sur/5jylNwWcOGVtBJ3bEGewf7JLwbJrpY2LUxwj92DLECfudE3uVlpVGlrPXyKYapA9 H1yc3NgwjRve8v2SGiIZGEu2TQDAlBD3bjDUzFPwr1kBUwjVLXE4764tZgl9hFDs1Yak lZrusYucIwYjDAT76FMkcFZmsRM6Gyn/Z02PodY4GX3iq+EfHcdaJnfC15T9MvKCvs4P ocEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687947999; x=1690539999; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QndBu+Ea73+5HZm45UHtALLqjv/Bpq0i3QEOMrOjFEA=; b=WjLFcKCL4h6AGxS4EU7lysKX1R49Foz0eo3qpEX7kw5VLz970CfmNTJ5aQz2s9eS/J ttOELcP3uF8R28CpZBuKAsLjq1PqrO0GtZGO5PXAh0c8qJxaxsxSgmByNFNwUGkWRYVW oA6qbXZQflv/Tlr996LVMFlSHdKujwDGC+o/qcaHHHiuoXaXWe2RKe/qLYuZYYCUWjfQ WA0FrhlG8G9OZHirB/vPx+978L98FTTzG/5+fx5/4EjFWXuED5kxZbic2sgwdukpfD6o YGNYYkRCLvCH6eJpvzDFJyd2Gj+H/qYrA8IlLo1c6PAFEGSM4vazlgLLHqoB9E2YKZwe 7KSA== X-Gm-Message-State: AC+VfDwl+WX1IZAL6PNqis6NHIzjtjsXObSMNTMl0ItWC0+v9zkPJZDb e3CDbZw/t2hRRSgUU8NeoySJrw== X-Received: by 2002:adf:e741:0:b0:313:ee2e:dae1 with SMTP id c1-20020adfe741000000b00313ee2edae1mr7605993wrn.18.1687947999424; Wed, 28 Jun 2023 03:26:39 -0700 (PDT) Received: from localhost.localdomain ([5.133.47.210]) by smtp.gmail.com with ESMTPSA id a10-20020a5d53ca000000b003140555c0ddsm2467780wrw.56.2023.06.28.03.26.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jun 2023 03:26:39 -0700 (PDT) From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> To: krzysztof.kozlowski+dt@linaro.org, andersson@kernel.org, broonie@kernel.org Cc: robh+dt@kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, dmitry.baryshkov@linaro.org, johan+linaro@kernel.org, perex@perex.cz, tiwai@suse.com, lgirdwood@gmail.com, ckeepax@opensource.cirrus.com, kuninori.morimoto.gx@renesas.com, linux-kernel@vger.kernel.org, pierre-louis.bossart@linux.intel.com, alsa-devel@alsa-project.org, Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Subject: [PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT Date: Wed, 28 Jun 2023 11:26:20 +0100 Message-Id: <20230628102621.15016-3-srinivas.kandagatla@linaro.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20230628102621.15016-1-srinivas.kandagatla@linaro.org> References: <20230628102621.15016-1-srinivas.kandagatla@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769943069335745114?= X-GMAIL-MSGID: =?utf-8?q?1769943069335745114?= |
Series |
ASoC: qcom: get tplg firmware-name from device tree
|
|
Commit Message
Srinivas Kandagatla
June 28, 2023, 10:26 a.m. UTC
Currently firmware file name is autogenerated based on card name and model number,
however this imposed a restriction of finding firmware in a single firmware path.
Platform specific firmwares are normally located in sub folders of the SoC.
Provide more flexibity by reading firmware-name from DT.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
sound/soc/qcom/qdsp6/topology.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
Comments
On Wed, Jun 28, 2023 at 11:26:20AM +0100, Srinivas Kandagatla wrote: > Currently firmware file name is autogenerated based on card name and model number, > however this imposed a restriction of finding firmware in a single firmware path. > Platform specific firmwares are normally located in sub folders of the SoC. > > Provide more flexibity by reading firmware-name from DT. Why not try a series of firmware names/locations generated using the identifying information for the card/system? That way we don't have to put a filename in the ABI which has fun scaling issues.
On 28/06/2023 12:53, Mark Brown wrote: > On Wed, Jun 28, 2023 at 11:26:20AM +0100, Srinivas Kandagatla wrote: >> Currently firmware file name is autogenerated based on card name and model number, >> however this imposed a restriction of finding firmware in a single firmware path. >> Platform specific firmwares are normally located in sub folders of the SoC. >> >> Provide more flexibity by reading firmware-name from DT. > > Why not try a series of firmware names/locations generated using the > identifying information for the card/system? That way we don't have to There is no consistent way with the current state of what is available in linux-firmware and what drivers can generate from DMI, atleast with Qualcomm SoCs. Example for x13s has all the firmwares are under qcom/sc8280xp/LENOVO/21BX for two models 21BX, 21BY. However none of the DMI properties match exactly to 21BX or 21BY. These have to be either derived from product name 21BYZ9SNUS or some other dmi properties. This logic is not going to be very reliable, can differ across platforms. All of the qcom platforms use firmware-name from DT to get the full firmware path with name. I know this has scaling issues, but with the current state of things, its the only option I see. > put a filename in the ABI which has fun scaling issues. thanks, srini
On 28/06/2023 14:53, Mark Brown wrote: > On Wed, Jun 28, 2023 at 11:26:20AM +0100, Srinivas Kandagatla wrote: >> Currently firmware file name is autogenerated based on card name and model number, >> however this imposed a restriction of finding firmware in a single firmware path. >> Platform specific firmwares are normally located in sub folders of the SoC. >> >> Provide more flexibity by reading firmware-name from DT. > > Why not try a series of firmware names/locations generated using the > identifying information for the card/system? That way we don't have to > put a filename in the ABI which has fun scaling issues. This is what was done by Srini in the initial (currently committed) version. Unfortunately this easily results in the audio topology being separated from the rest of the platform-specific firmware. For example, for the mentioned X13s we already have a subdir under /lib/firmware/qcom and several firmware-name DT properties pointing to the files in that subdir: $ grep firmware-name arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts firmware-name = "qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn"; firmware-name = "qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn"; firmware-name = "qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn"; This is not unique to the X13s, other Qualcomm boards also use full paths.
On Wed, Jun 28, 2023 at 05:30:15PM +0100, Srinivas Kandagatla wrote: > On 28/06/2023 12:53, Mark Brown wrote: > > Why not try a series of firmware names/locations generated using the > > identifying information for the card/system? That way we don't have to > There is no consistent way with the current state of what is available in > linux-firmware and what drivers can generate from DMI, atleast with Qualcomm > SoCs. What's in linux-firmware now is not relevant, we can change that however we like. > Example for x13s has all the firmwares are under qcom/sc8280xp/LENOVO/21BX > for two models 21BX, 21BY. > However none of the DMI properties match exactly to 21BX or 21BY. > These have to be either derived from product name 21BYZ9SNUS or some other > dmi properties. > This logic is not going to be very reliable, can differ across platforms. But the goal here is to have platform specific firmwares so that's fine? So long as we come up with something stable and platform specific userspace will have the information to provide the firmware it likes, even if that does end up involving a lot of symlinks. > All of the qcom platforms use firmware-name from DT to get the full firmware > path with name. > I know this has scaling issues, but with the current state of things, its > the only option I see. When you say "all the qcom platforms" what do you mean, you're proposing a new property here?
On Wed, Jun 28, 2023 at 07:57:38PM +0300, Dmitry Baryshkov wrote: > On 28/06/2023 14:53, Mark Brown wrote: > > Why not try a series of firmware names/locations generated using the > > identifying information for the card/system? That way we don't have to > > put a filename in the ABI which has fun scaling issues. > This is what was done by Srini in the initial (currently committed) version. > Unfortunately this easily results in the audio topology being separated from > the rest of the platform-specific firmware. For example, for the mentioned > X13s we already have a subdir under /lib/firmware/qcom and several > firmware-name DT properties pointing to the files in that subdir: > $ grep firmware-name > arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts > firmware-name = "qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn"; > firmware-name = "qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn"; > firmware-name = "qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn"; > This is not unique to the X13s, other Qualcomm boards also use full paths. If the goal here is to put all the firmwares for a given board in a single place surely it would be better to factor this all out of the individual drivers so that they ask some helper for a directory to use for firmware? Adding these device specific firmware node properties doesn't seem to follow.
On 28/06/2023 21:10, Mark Brown wrote: > On Wed, Jun 28, 2023 at 07:57:38PM +0300, Dmitry Baryshkov wrote: >> On 28/06/2023 14:53, Mark Brown wrote: > >>> Why not try a series of firmware names/locations generated using the >>> identifying information for the card/system? That way we don't have to >>> put a filename in the ABI which has fun scaling issues. > >> This is what was done by Srini in the initial (currently committed) version. >> Unfortunately this easily results in the audio topology being separated from >> the rest of the platform-specific firmware. For example, for the mentioned >> X13s we already have a subdir under /lib/firmware/qcom and several >> firmware-name DT properties pointing to the files in that subdir: > >> $ grep firmware-name >> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts >> firmware-name = "qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn"; >> firmware-name = "qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn"; >> firmware-name = "qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn"; > >> This is not unique to the X13s, other Qualcomm boards also use full paths. > > If the goal here is to put all the firmwares for a given board in a > single place surely it would be better to factor this all out of the > individual drivers so that they ask some helper for a directory to use > for firmware? Adding these device specific firmware node properties > doesn't seem to follow. This quickly becomes overcomplicated. Some platforms use different firmware naming structure. Some firmware goes into a generic location and other files go into device-specific location. So having a generic helper doesn't really help.
On Wed, Jun 28, 2023 at 10:33:16PM +0300, Dmitry Baryshkov wrote: > On 28/06/2023 21:10, Mark Brown wrote: > > If the goal here is to put all the firmwares for a given board in a > > single place surely it would be better to factor this all out of the > > individual drivers so that they ask some helper for a directory to use > > for firmware? Adding these device specific firmware node properties > > doesn't seem to follow. > This quickly becomes overcomplicated. Some platforms use different firmware > naming structure. Some firmware goes into a generic location and other files > go into device-specific location. So having a generic helper doesn't really > help. That sounds like a job for symlinks surely?
On Wed, 28 Jun 2023 at 22:40, Mark Brown <broonie@kernel.org> wrote: > > On Wed, Jun 28, 2023 at 10:33:16PM +0300, Dmitry Baryshkov wrote: > > On 28/06/2023 21:10, Mark Brown wrote: > > > > If the goal here is to put all the firmwares for a given board in a > > > single place surely it would be better to factor this all out of the > > > individual drivers so that they ask some helper for a directory to use > > > for firmware? Adding these device specific firmware node properties > > > doesn't seem to follow. > > > This quickly becomes overcomplicated. Some platforms use different firmware > > naming structure. Some firmware goes into a generic location and other files > > go into device-specific location. So having a generic helper doesn't really > > help. > > That sounds like a job for symlinks surely? Excuse me, but I don't understand the goal for such symlinks. In my opinion (and more importantly, in the opinion of qcom maintainers), firmware-name does the necessary job. It provides enough flexibility and doesn't require any additional dances around.
On Wed, Jun 28, 2023 at 11:00:54PM +0300, Dmitry Baryshkov wrote: > On Wed, 28 Jun 2023 at 22:40, Mark Brown <broonie@kernel.org> wrote: > > On Wed, Jun 28, 2023 at 10:33:16PM +0300, Dmitry Baryshkov wrote: > > > This quickly becomes overcomplicated. Some platforms use different firmware > > > naming structure. Some firmware goes into a generic location and other files > > > go into device-specific location. So having a generic helper doesn't really > > > help. > > That sounds like a job for symlinks surely? > Excuse me, but I don't understand the goal for such symlinks. In my > opinion (and more importantly, in the opinion of qcom maintainers), > firmware-name does the necessary job. It provides enough flexibility > and doesn't require any additional dances around. The goal is to avoid adding a Linux specific ABI if we don't need one, and to allow later adjustment of what's selected on the userspace side more easily (eg, if a more specific firwmare is found).
diff --git a/sound/soc/qcom/qdsp6/topology.c b/sound/soc/qcom/qdsp6/topology.c index cccc59b570b9..ccb4efc15648 100644 --- a/sound/soc/qcom/qdsp6/topology.c +++ b/sound/soc/qcom/qdsp6/topology.c @@ -1258,16 +1258,16 @@ static struct snd_soc_tplg_ops audioreach_tplg_ops = { int audioreach_tplg_init(struct snd_soc_component *component) { - struct snd_soc_card *card = component->card; struct device *dev = component->dev; const struct firmware *fw; - char *tplg_fw_name; + const char *tplg_fw_name; int ret; - /* Inline with Qualcomm UCM configs and linux-firmware path */ - tplg_fw_name = kasprintf(GFP_KERNEL, "qcom/%s/%s-tplg.bin", card->driver_name, card->name); - if (!tplg_fw_name) - return -ENOMEM; + ret = of_property_read_string(dev->of_node, "firmware-name", &tplg_fw_name); + if (ret < 0) { + dev_err(dev, "firmware-name property missing in Device tree\n"); + return ret; + } ret = request_firmware(&fw, tplg_fw_name, dev); if (ret < 0) { @@ -1283,8 +1283,6 @@ int audioreach_tplg_init(struct snd_soc_component *component) release_firmware(fw); err: - kfree(tplg_fw_name); - return ret; } EXPORT_SYMBOL_GPL(audioreach_tplg_init);