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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux