|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2 |
|
| #
a0b887f6 |
| 11-Apr-2025 |
Nico Pache <[email protected]> |
firmware: cs_dsp: tests: Depend on FW_CS_DSP rather then enabling it
FW_CS_DSP gets enabled if KUNIT is enabled. The test should rather depend on if the feature is enabled. Fix this by moving FW_CS_
firmware: cs_dsp: tests: Depend on FW_CS_DSP rather then enabling it
FW_CS_DSP gets enabled if KUNIT is enabled. The test should rather depend on if the feature is enabled. Fix this by moving FW_CS_DSP to the depends on clause.
Fixes: dd0b6b1f29b9 ("firmware: cs_dsp: Add KUnit testing of bin file download") Signed-off-by: Nico Pache <[email protected]> Signed-off-by: Richard Fitzgerald <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: David Gow <[email protected]> Signed-off-by: Mark Brown <[email protected]>
show more ...
|
|
Revision tags: v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1 |
|
| #
eb5c7982 |
| 25-Jan-2025 |
Geert Uytterhoeven <[email protected]> |
firmware: cs_dsp: FW_CS_DSP_KUNIT_TEST should not select REGMAP
Enabling a (modular) test should not silently enable additional kernel functionality, as that may increase the attack vector of a prod
firmware: cs_dsp: FW_CS_DSP_KUNIT_TEST should not select REGMAP
Enabling a (modular) test should not silently enable additional kernel functionality, as that may increase the attack vector of a product.
Fix this by making FW_CS_DSP_KUNIT_TEST (and FW_CS_DSP_KUNIT_TEST_UTILS) depend on REGMAP instead of selecting it.
After this, one can safely enable CONFIG_KUNIT_ALL_TESTS=m to build modules for all appropriate tests for ones system, without pulling in extra unwanted functionality, while still allowing a tester to manually enable REGMAP_BUILD and this test suite on a system where REGMAP is not enabled by default.
Fixes: dd0b6b1f29b92202 ("firmware: cs_dsp: Add KUnit testing of bin file download") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/73c81ac85e21f1c5a75b7628d90cbb0e1b4ed0fa.1737833376.git.geert@linux-m68k.org Signed-off-by: Mark Brown <[email protected]>
show more ...
|
|
Revision tags: v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3 |
|
| #
dd0b6b1f |
| 12-Dec-2024 |
Richard Fitzgerald <[email protected]> |
firmware: cs_dsp: Add KUnit testing of bin file download
This adds a KUnit test suite to test downloading bin files.
The general technique is 1. Create mock bin file content 2. Tell cs_dsp to downl
firmware: cs_dsp: Add KUnit testing of bin file download
This adds a KUnit test suite to test downloading bin files.
The general technique is 1. Create mock bin file content 2. Tell cs_dsp to download the bin file 3. Check in the emulated regmap registers that the correct values have been written to DSP memory 4. Drop the regmap cache for the expected written registers and then do a regcache_sync() to check for unexpected writes to other registers.
The test covers ADSP2 v1 and v2, and HALO Core DSPs. (ADSP1 is very obsolete so isn't tested).
There is a large number of test cases and parameterized variants of tests because of the many different addressing schemes supported by the Cirrus devices. The DSP has 2 or 3 memory spaces: XM, YM and ZM. The DSP sees these using its native addressing, which is word-addressed (not byte-addressed). The host sees these through one of several register mappings (depending on the DSP type and parent codec family). The registers have three different addressing schemes: 16-bit registers addressed by register number, 32-bit registers addressed by register number, or 32-bit registers addressed by byte (with a stride of 4). In addition to these multiple addressing schemes, the Halo Core DSPs have a "packed" register mapping that maps 4 DSP words into 3 registers. The bin file addresses the data blob relative to the base address of an algorithm, which has to be calculated in both DSP words (for the DSP to access) and register addresses (for the host).
This results in many different addressing schemes used in parallel, hence the complexity of the address and size manipulation in the test cases: word addresses in DSP memory, byte offsets, word offsets, register addresses (either byte-addressed 32-bit or index-addressed 16-bit), and packed register addresses.
The test cases intentionally have relatively little factoring-out of similar code. This makes it much easier to visually verify that a test case is testing correctly, and what exactly it is testing. Factoring out large amounts of code into helper functions tends to obscure what the actual test procedure is, so increasing the chance of hidden errors where test cases don't actually test as intended.
Signed-off-by: Richard Fitzgerald <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
show more ...
|
| #
d54a3fc6 |
| 12-Dec-2024 |
Richard Fitzgerald <[email protected]> |
firmware: cs_dsp: Add mock regmap for KUnit testing
Add a mock regmap implementation to act as a simulated DSP for KUnit testing. This is built as a utility module so that it could be used by client
firmware: cs_dsp: Add mock regmap for KUnit testing
Add a mock regmap implementation to act as a simulated DSP for KUnit testing. This is built as a utility module so that it could be used by clients of cs_dsp to create a mock "DSP" for their own testing.
cs_dsp interacts with the DSP only through registers. Most of the register space of the DSP is RAM. ADSP cores have a small set of control registers. HALO Core DSPs have a much larger set of control registers but only a small subset are used.
Most writes are "blind" in the sense that cs_dsp does not expect to receive any sort of response from the DSP. So there isn't any need to emulate a "DSP", only a set of registers that can be written and read back.
The idea of the mock regmap is to use the cache to accumulate writes which can then be tested against the values that are expected to be in the registers.
Stray writes can be detected by dropping the cache entries for all addresses that should have been written and then issuing a regcache_sync(). If this causes bus writes it means there were writes to unexpected registers.
Signed-off-by: Richard Fitzgerald <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
show more ...
|
|
Revision tags: v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7 |
|
| #
d7cfdf17 |
| 24-Nov-2022 |
Richard Fitzgerald <[email protected]> |
firmware: cs_dsp: Rename KConfig symbol CS_DSP -> FW_CS_DSP
Qualify the KConfig symbol for cs_dsp by adding a FW_ prefix so that it is more explicit what is being referred to. This is preparation fo
firmware: cs_dsp: Rename KConfig symbol CS_DSP -> FW_CS_DSP
Qualify the KConfig symbol for cs_dsp by adding a FW_ prefix so that it is more explicit what is being referred to. This is preparation for using the symbol to namespace the exports.
Signed-off-by: Richard Fitzgerald <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
show more ...
|
|
Revision tags: v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2 |
|
| #
f6bc909e |
| 13-Sep-2021 |
Simon Trimmer <[email protected]> |
firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs
wm_adsp originally provided firmware loading on some audio DSP and was implemented as an ASoC codec driver. However, the
firmware: cs_dsp: add driver to support firmware loading on Cirrus Logic DSPs
wm_adsp originally provided firmware loading on some audio DSP and was implemented as an ASoC codec driver. However, the firmware loading now covers a wider range of DSP cores and peripherals containing them, beyond just audio. So it needs to be available to non-audio drivers. All the core firmware loading support has been moved into a new driver cs_dsp, leaving only the ASoC-specific parts in wm_adsp.
Signed-off-by: Simon Trimmer <[email protected]> Signed-off-by: Charles Keepax <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
show more ...
|