[PATCH 0/3] ASoC: qcom: get tplg firmware-name from device tree

[PATCH 0/3] ASoC: qcom: get tplg firmware-name from device tree

[Srinivas Kandagatla]

With the existing setup the firmware file is looked up in a fixed location
based on soundcard name, however this is not really scalable and not inline
with where linux-firmware stores board specific firmwares.

This patchset adds a new binding to q6apm to allow board specific Device Tree
to pass firmware-name, this also makes it inline with how other firmwares are
specified in qcom boards.


Srinivas Kandagatla (3):
  ASoC: dt-bindings: q6apm: add firmware-name bindings
  ASoC: qcom: q6apm: add support for reading firmware name from DT
  arm64: dts: qcom: sc8280xp-x13s: Add audio topology firmware path

 .../devicetree/bindings/sound/qcom,q6apm.yaml      |  5 +++++
 .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts     |  5 +++++
 sound/soc/qcom/qdsp6/topology.c                    | 14 ++++++--------
 3 files changed, 16 insertions(+), 8 deletions(-)

-- 
2.21.0

[PATCH 1/3] ASoC: dt-bindings: q6apm: add firmware-name bindings

[Srinivas Kandagatla]

Add bindings to get firmare-name from DT, this will provide more flexibility
to specify platform specific firmware file name and location. Also this brings
tplg firmware name inline with other board specific firmware locations.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 Documentation/devicetree/bindings/sound/qcom,q6apm.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
index ef1965aca254..c783451145ef 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
@@ -31,6 +31,10 @@ properties:
     unevaluatedProperties: false
     description: Qualcomm DSP audio ports
 
+  firmware-name:
+    $ref: /schemas/types.yaml#/definitions/string
+    description: Audio Topology Firmware name
+
   '#sound-dai-cells':
     const: 0
 
@@ -38,6 +42,7 @@ required:
   - compatible
   - bedais
   - dais
+  - firmware-name
 
 unevaluatedProperties: false
 
-- 
2.21.0

Re: [PATCH 1/3] ASoC: dt-bindings: q6apm: add firmware-name bindings

[Rob Herring]

On Wed, 28 Jun 2023 11:26:19 +0100, Srinivas Kandagatla wrote:
> Add bindings to get firmare-name from DT, this will provide more flexibility
> to specify platform specific firmware file name and location. Also this brings
> tplg firmware name inline with other board specific firmware locations.
> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
>  Documentation/devicetree/bindings/sound/qcom,q6apm.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/clock/milbeaut-clock.example.dtb: /example-2/serial@1e700010: failed to match any schema with compatible: ['socionext,milbeaut-usio-uart']
Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.example.dtb: /example-1/syscon@20e00000: failed to match any schema with compatible: ['sprd,sc9863a-glbregs', 'syscon', 'simple-mfd']
Documentation/devicetree/bindings/leds/common.example.dtb: /example-2/i2c/led-controller@30: failed to match any schema with compatible: ['panasonic,an30259a']
Documentation/devicetree/bindings/sound/audio-graph-card2.example.dtb: /example-0/cpu: failed to match any schema with compatible: ['cpu-driver']
Documentation/devicetree/bindings/sound/audio-graph-card2.example.dtb: /example-0/codec: failed to match any schema with compatible: ['codec-driver']
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/qcom,q6apm.example.dtb: service@1: 'firmware-name' is a required property
	from schema $id: http://devicetree.org/schemas/sound/qcom,q6apm.yaml#
Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.example.dtb: /example-0/avs-monitor@7d5d2000: failed to match any schema with compatible: ['brcm,bcm2711-avs-monitor', 'syscon', 'simple-mfd']
Documentation/devicetree/bindings/thermal/imx-thermal.example.dtb: /example-0/anatop@20c8000: failed to match any schema with compatible: ['fsl,imx6q-anatop', 'syscon', 'simple-mfd']
Documentation/devicetree/bindings/i2c/qcom,i2c-cci.example.dtb: /example-0/cci@ac4a000/i2c-bus@1/camera@60: failed to match any schema with compatible: ['ovti,ov7251']
Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.example.dtb: /example-0/pmic: failed to match any schema with compatible: ['ti,twl6035-pmic', 'ti,palmas-pmic']
Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.example.dtb: /example-0/pmic: failed to match any schema with compatible: ['ti,twl6035-pmic', 'ti,palmas-pmic']
Documentation/devicetree/bindings/input/mediatek,pmic-keys.example.dtb: /example-0/pmic: failed to match any schema with compatible: ['mediatek,mt6397']
Documentation/devicetree/bindings/input/sprd,sc27xx-vibrator.example.dtb: /example-0/pmic@0: failed to match any schema with compatible: ['sprd,sc2731']
Documentation/devicetree/bindings/dma/dma-controller.example.dtb: /example-0/dma-controller@48000000: failed to match any schema with compatible: ['ti,omap-sdma']
Documentation/devicetree/bindings/dma/dma-router.example.dtb: /example-0/dma-router@4a002b78: failed to match any schema with compatible: ['ti,dra7-dma-crossbar']
Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.example.dtb: /example-0/memory-controller@13410000/ethernet@6: failed to match any schema with compatible: ['davicom,dm9000']
Documentation/devicetree/bindings/arm/hisilicon/controller/cpuctrl.example.dtb: /example-0/cpuctrl@a22000/clock@0: failed to match any schema with compatible: ['hisilicon,hix5hd2-clock']
Documentation/devicetree/bindings/arm/hisilicon/controller/hi3798cv200-perictrl.example.dtb: /example-0/peripheral-controller@8a20000/phy@850: failed to match any schema with compatible: ['hisilicon,hi3798cv200-combphy']
Documentation/devicetree/bindings/arm/hisilicon/controller/sysctrl.example.dtb: /example-0/system-controller@802000/clock@0: failed to match any schema with compatible: ['hisilicon,hi3620-clock']
Documentation/devicetree/bindings/media/rockchip-isp1.example.dtb: /example-0/parent/i2c/camera@36: failed to match any schema with compatible: ['ovti,ov5695']
Documentation/devicetree/bindings/net/marvell,mvusb.example.dtb: /example-0/usb/mdio@1/switch@0: failed to match any schema with compatible: ['marvell,mv88e6190']
Documentation/devicetree/bindings/net/qca,ar71xx.example.dtb: /example-0/ethernet@1a000000/mdio/switch@10: failed to match any schema with compatible: ['qca,ar9331-switch']
Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.example.dtb: /example-0/iomcu@ffd7e000: failed to match any schema with compatible: ['hisilicon,hi3660-iomcu', 'syscon']
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/qcom/qcom,apr.example.dtb: service@1: 'firmware-name' is a required property
	from schema $id: http://devicetree.org/schemas/sound/qcom,q6apm.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230628102621.15016-2-srinivas.kandagatla@linaro.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH 1/3] ASoC: dt-bindings: q6apm: add firmware-name bindings

[Rob Herring]

On Wed, Jun 28, 2023 at 11:26:19AM +0100, Srinivas Kandagatla wrote:
> Add bindings to get firmare-name from DT, this will provide more flexibility
> to specify platform specific firmware file name and location. Also this brings
> tplg firmware name inline with other board specific firmware locations.

tplg?

> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
>  Documentation/devicetree/bindings/sound/qcom,q6apm.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
> index ef1965aca254..c783451145ef 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
> @@ -31,6 +31,10 @@ properties:
>      unevaluatedProperties: false
>      description: Qualcomm DSP audio ports
>  
> +  firmware-name:
> +    $ref: /schemas/types.yaml#/definitions/string

Already has a type, so you can drop.

No default? Or pattern it should match? 

> +    description: Audio Topology Firmware name
> +
>    '#sound-dai-cells':
>      const: 0
>  
> @@ -38,6 +42,7 @@ required:
>    - compatible
>    - bedais
>    - dais
> +  - firmware-name

Causes warnings. Test you bindings.

>  
>  unevaluatedProperties: false
>  
> -- 
> 2.21.0
> 

Re: [PATCH 1/3] ASoC: dt-bindings: q6apm: add firmware-name bindings

[Srinivas Kandagatla]

On 28/06/2023 16:54, Rob Herring wrote:
> On Wed, Jun 28, 2023 at 11:26:19AM +0100, Srinivas Kandagatla wrote:
>> Add bindings to get firmare-name from DT, this will provide more flexibility
>> to specify platform specific firmware file name and location. Also this brings
>> tplg firmware name inline with other board specific firmware locations.
> 
> tplg?
Topology, will update this in next version.

> 
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>>   Documentation/devicetree/bindings/sound/qcom,q6apm.yaml | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
>> index ef1965aca254..c783451145ef 100644
>> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
>> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm.yaml
>> @@ -31,6 +31,10 @@ properties:
>>       unevaluatedProperties: false
>>       description: Qualcomm DSP audio ports
>>   
>> +  firmware-name:
>> +    $ref: /schemas/types.yaml#/definitions/string
> 
> Already has a type, so you can drop.
thankyou removed this now, but all the existing yaml still have this.

> 
> No default? Or pattern it should match?

no, its going to be hard to come up with a pattern to match file name or 
path for firmware.

> 
>> +    description: Audio Topology Firmware name
>> +
>>     '#sound-dai-cells':
>>       const: 0
>>   
>> @@ -38,6 +42,7 @@ required:
>>     - compatible
>>     - bedais
>>     - dais
>> +  - firmware-name
> 
> Causes warnings. Test you bindings.

yes, examples need updating, will do that in next spin.

--srini
> 
>>   
>>   unevaluatedProperties: false
>>   
>> -- 
>> 2.21.0
>>

[PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT

[Srinivas Kandagatla]

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

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);
-- 
2.21.0

Re: [PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT

[Srinivas Kandagatla]

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

Re: [PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT

[Dmitry Baryshkov]

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.

-- 
With best wishes
Dmitry

Re: [PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT

[Dmitry Baryshkov]

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.

-- 
With best wishes
Dmitry

Re: [PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT

[Dmitry Baryshkov]

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.



-- 
With best wishes
Dmitry

Re: [PATCH 2/3] ASoC: qcom: q6apm: add support for reading firmware name from DT

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH 3/3] arm64: dts: qcom: sc8280xp-x13s: Add audio topology firmware path

[Srinivas Kandagatla]

Add audio topology firmware name and path in dt so that we can
specify full path for it.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
index 7cc3028440b6..0160b8e7d64f 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
+++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
@@ -924,6 +924,11 @@
 	};
 };
 
+
+&q6apm {
+	firmware-name = "qcom/sc8280xp/LENOVO/21BX/audioreach-tplg.bin";
+};
+
 &qup0 {
 	status = "okay";
 };
-- 
2.21.0