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

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

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