| Message ID | 20230628102621.15016-3-srinivas.kandagatla@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ASoC: qcom: get tplg firmware-name from device tree | expand |
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);
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(-)