linux/tools/testing/selftests/alsa, branch v6.4

selftests: alsa: pcm-test: Fix compiler warnings about the format

2023-06-05T07:15:42Z

GCC 11.3.0 issues warnings in this module about wrong sizes of format specifiers: pcm-test.c: In function ‘test_pcm_time’: pcm-test.c:384:68: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 \ has type ‘unsigned int’ [-Wformat=] 384 | snprintf(msg, sizeof(msg), "rate mismatch %ld != %ld", rate, rrate); pcm-test.c:455:53: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has \ type ‘long int’ [-Wformat=] 455 | "expected %d, wrote %li", rate, frames); pcm-test.c:462:53: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has \ type ‘long int’ [-Wformat=] 462 | "expected %d, wrote %li", rate, frames); pcm-test.c:467:53: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has \ type ‘long int’ [-Wformat=] 467 | "expected %d, wrote %li", rate, frames); Simple fix according to compiler's suggestion removed the warnings. Signed-off-by: Mirsad Goran Todorovac Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20230524191528.13203-1-mirsad.todorovac@alu.unizg.hr Signed-off-by: Takashi Iwai

kselftest/alsa - pcm-test: Don't include diagnostic message in test name

2023-03-24T06:49:57Z

When reporting errors or skips we currently include the diagnostic message indicating why we're failing or skipping. This isn't ideal since KTAP defines the entire print as the test name, so if there's an error then test systems won't detect the test as being the same one as a passing test. Move the diagnostic to a separate ksft_print_msg() to avoid this issue, the test name part will always be the same for passes, fails and skips and the diagnostic information is still displayed. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230323-alsa-pcm-test-names-v1-1-8be67a8885ff@kernel.org Signed-off-by: Takashi Iwai

kselftest/alsa - mixer-test: Log values associated with event issues

2023-03-24T06:49:47Z

While it is common for driver bugs with events to apply to all events there are some issues which only trigger for specific values. Understanding these is easier if we know what we were trying to do when configuring the control so add logging for the specific values involved in the spurious event. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230322-alsa-mixer-event-values-v1-1-78189fcf6655@kernel.org Signed-off-by: Takashi Iwai

kselftest/alsa: Log card names during startup

2023-03-08T05:35:25Z

It can be helpful to know which card numbers apply to which cards in a multi-card system so log the card names when we start the test programs. People looking at the logs may not have direct access to the systems being tested. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230223-alsa-log-ctl-name-v1-2-ac0f10cc4db2@kernel.org Signed-off-by: Takashi Iwai

kselftest/alsa - mixer: Always log control names

2023-03-08T05:35:18Z

Currently we only log the names of controls on error but it can be useful to know what control we're testing (for example, when looking at why the tests are taking a while to run). People looking at test logs may not have direct access to the target system. This will increase the amount we write to the console, hopefully that's buffered. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230223-alsa-log-ctl-name-v1-1-ac0f10cc4db2@kernel.org Signed-off-by: Takashi Iwai

kselftest/alsa - mixer-test: Don't fail tests if we can't restore default

2023-03-08T05:34:29Z

If a control has an invalid default value then we might fail to set it when restoring the default value after our write tests, for example due to correctly implemented range checks in put() operations. Currently this causes us to report the tests we were running as failed even when the operation we were trying to test is successful, making it look like there are problems where none really exist. Stop doing this, only reporting any issues during the actual test. We already have validation for the initial readback being in spec and for writing the default value back so failed tests will be reported for these controls, and we log an error on the operation that failed when we write so there will be a diagnostic warning the user that there is a problem. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230224-alsa-mixer-test-restore-invalid-v1-1-454f0f1f2c4b@kernel.org Signed-off-by: Takashi Iwai

kselftest/alsa: Run PCM tests for multiple cards in parallel

2023-02-04T08:36:35Z

With each test taking 4 seconds the runtime of pcm-test can add up. Since generally each card in the system is physically independent and will be unaffected by what's going on with other cards we can mitigate this by testing each card in parallel. Make a list of cards as we enumerate the system and then start a thread for each, then join the threads to ensure they have all finished. The threads each run the same tests we currently run for each PCM on the card before exiting. The list of PCMs is kept global since it helps with global operations like working out our planned number of tests and identifying missing PCMs and it seemed neater to check for PCMs on the right card in the card thread than make every PCM loop iterate over cards as well. We don't run per-PCM tests in parallel since in embedded systems it can be the case that resources are shared between the PCMs and operations on one PCM on a card may constrain what can be done on another PCM on the same card leading to potentially unstable results. We use a mutex to ensure that the reporting of results is serialised and we don't have issues with anything like the current test number, we could do this in the kselftest framework but it seems like this might cause problems for other tests that are doing lower level testing and building in constrained environments such as nolibc so this seems more sensible. Note that the ordering of the tests can't be guaranteed as things stand, this does not seem like a major problem since the numbering of tests often changes as test programs are changed so results parsers are expected to rely on the test name rather than the test numbers. We also now prefix the machine generated test name when printing the description of the test since this is logged before streaming starts. On my two card desktop system this reduces the overall runtime by a third. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20230203-alsa-pcm-test-card-thread-v1-1-59941640ebba@kernel.org Signed-off-by: Takashi Iwai

kselftest/alsa: pcm - Add more coverage by default

2023-01-02T14:08:24Z

Add more coverage to our standard test cases: - 8kHz mono and stereo to verify that the most common mono format is clocked correctly. - 44.1kHz stereo to verify that this different clock base is generated accurately. - 48kHz 6 channel to verify that 6 channel is clocked correctly. - 96kHz stereo since that is a common audiophile rate. Reviewed-by: Jaroslav Kysela Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20221208-alsa-pcm-test-hacks-v4-7-5a152e65b1e1@kernel.org Signed-off-by: Takashi Iwai

kselftest/alsa: pcm - Provide descriptions for the default tests

2023-01-02T14:08:17Z

Help people understand what the standard tests are trying to cover by providing descriptions which both serve as comments in the file and log messages in the program's output. Reviewed-by: Jaroslav Kysela Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20221208-alsa-pcm-test-hacks-v4-6-5a152e65b1e1@kernel.org Signed-off-by: Takashi Iwai

kselftest/alsa: pcm - Support optional description for tests

2023-01-02T14:08:07Z

In order to help with the comprehensibility of tests it is useful for us to document what the test is attempting to cover. We could just do this through comments in the configuration files but in order to aid people looking at the output of the program in logs let's provide support for an optional 'description' directive which we log prior to running each of the tests. Reviewed-by: Jaroslav Kysela Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20221208-alsa-pcm-test-hacks-v4-5-5a152e65b1e1@kernel.org Signed-off-by: Takashi Iwai