2022-07-07 15:38:51

by Stefan Binding

[permalink] [raw]
Subject: [PATCH v6 0/2] Read _SUB from ACPI to be able to identify firmware

CS35L41 has a DSP which is able to run firmware, as well as a tuning file.
Different systems may want to use different firmwares and tuning files, and
some firmwares/tunings may not be compatible with other systems.
To allow a system to select the correct fimware/tuning, we can read an _SUB
from the ACPI. This _SUB can then be used to uniquely identify the system
in the firmware/tuning file name.

Add a helper function which reads the _SUB, so this can be used by other
parts in the future.
Add support inside the CS35L41 ASoC driver to read this _SUB, and save it
appropriately.

Changes since v5:
- Clean up return codes
- Refactor length calculation
- Allow fallback to existing behaviour when bad ACPI is detected

Changes since v4:
- Rename function

Changes since v3:
- Fix 32 bit format string warning

Changes since v2:
- Fix error in function prototype

Changes since v1:
- Add length validation for SSID String
- Rename API
- Allocate memory inside API
- Use ACPI_HANDLE macro instead of ACPI_COMPANION
- Improve error handling

Stefan Binding (2):
ACPI: utils: Add api to read _SUB from ACPI
ASoC: cs35l41: Read System Name from ACPI _SUB to identify firmware

drivers/acpi/utils.c | 38 ++++++++++++++++++++++++++++++++++++++
include/linux/acpi.h | 6 ++++++
sound/soc/codecs/cs35l41.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 74 insertions(+)

--
2.25.1


2022-07-07 16:02:42

by Stefan Binding

[permalink] [raw]
Subject: [PATCH v6 2/2] ASoC: cs35l41: Read System Name from ACPI _SUB to identify firmware

When loading firmware, wm_adsp uses a number of parameters to
determine the path of the firmware and tuning files to load.
One of these parameters is system_name.
Add support in cs35l41 to read this system name from the ACPI
_SUB ID in order to uniquely identify the firmware and tuning
mapped to a particular system.

Signed-off-by: Stefan Binding <[email protected]>
---
sound/soc/codecs/cs35l41.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)

diff --git a/sound/soc/codecs/cs35l41.c b/sound/soc/codecs/cs35l41.c
index 8766e19d85f1..c223d83e02cf 100644
--- a/sound/soc/codecs/cs35l41.c
+++ b/sound/soc/codecs/cs35l41.c
@@ -6,6 +6,7 @@
//
// Author: David Rhodes <[email protected]>

+#include <linux/acpi.h>
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/init.h>
@@ -1142,6 +1143,30 @@ static int cs35l41_dsp_init(struct cs35l41_private *cs35l41)
return ret;
}

+static int cs35l41_acpi_get_name(struct cs35l41_private *cs35l41)
+{
+ acpi_handle handle = ACPI_HANDLE(cs35l41->dev);
+ const char *sub;
+
+ /* If there is no ACPI_HANDLE, there is no ACPI for this system, return 0 */
+ if (!handle)
+ return 0;
+
+ sub = acpi_get_subsystem_id(handle);
+ if (IS_ERR(sub)) {
+ /* If bad ACPI, return 0 and fallback to legacy firmware path, otherwise fail */
+ if (PTR_ERR(sub) == -ENODATA)
+ return 0;
+ else
+ return PTR_ERR(sub);
+ }
+
+ cs35l41->dsp.system_name = sub;
+ dev_dbg(cs35l41->dev, "Subsystem ID: %s\n", cs35l41->dsp.system_name);
+
+ return 0;
+}
+
int cs35l41_probe(struct cs35l41_private *cs35l41, const struct cs35l41_hw_cfg *hw_cfg)
{
u32 regid, reg_revid, i, mtl_revid, int_status, chipid_match;
@@ -1270,6 +1295,10 @@ int cs35l41_probe(struct cs35l41_private *cs35l41, const struct cs35l41_hw_cfg *
goto err;
}

+ ret = cs35l41_acpi_get_name(cs35l41);
+ if (ret < 0)
+ goto err;
+
ret = cs35l41_dsp_init(cs35l41);
if (ret < 0)
goto err;
@@ -1316,6 +1345,7 @@ void cs35l41_remove(struct cs35l41_private *cs35l41)
pm_runtime_disable(cs35l41->dev);

regmap_write(cs35l41->regmap, CS35L41_IRQ1_MASK1, 0xFFFFFFFF);
+ kfree(cs35l41->dsp.system_name);
wm_adsp2_remove(&cs35l41->dsp);
cs35l41_safe_reset(cs35l41->regmap, cs35l41->hw_cfg.bst_type);

--
2.25.1

2022-07-15 17:30:47

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH v6 0/2] Read _SUB from ACPI to be able to identify firmware

On Thu, 7 Jul 2022 16:10:35 +0100, Stefan Binding wrote:
> CS35L41 has a DSP which is able to run firmware, as well as a tuning file.
> Different systems may want to use different firmwares and tuning files, and
> some firmwares/tunings may not be compatible with other systems.
> To allow a system to select the correct fimware/tuning, we can read an _SUB
> from the ACPI. This _SUB can then be used to uniquely identify the system
> in the firmware/tuning file name.
>
> [...]

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/2] ACPI: utils: Add api to read _SUB from ACPI
commit: 93064e15c8a3a8394319a11b8037666e4b7d653d
[2/2] ASoC: cs35l41: Read System Name from ACPI _SUB to identify firmware
commit: c1ad138822a1be95a7a7b122521c2415583a0c26

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark