Rework the way that kernel log messages are rate-limited or suppressed
while running the cs_dsp KUnit tests.

Under normal conditions cs_dsp doesn't produce an unreasonable number of
log messages, and state changes are relatively infrequent. But the KUnit
tests run through a very large number of test cases, especially error
cases, and this produces an unusually large amount of log output from
cs_dsp.

The original fix for this in commit 10db9f6899dd ("firmware: cs_dsp:
rate-limit log messages in KUnit builds") was effective but not pretty.
It involved different definitions of the log macros for KUnit and
not-KUnit builds, and exported variables for the KUnit tests to disable
log messages. I would have preferred to turn the log macros into real
functions that can contain a KUNIT_STATIC_STUB_REDIRECT(), but the
dev_xxx() macros don't have a version that take va_args, so they can't
be wrapped by a function.

This patch enables the use of a KUNIT_STATIC_STUB_REDIRECT() instead
of exported variables, and avoids the need for different definitions of
the debug macros in KUnit and not-KUnit builds.

- A new function cs_dsp_can_emit_message() returns true if the
  messages can be emitted to the kernel log. In a normal not-KUnit build
  this function collapses to simply returning true. In KUnit builds it
  will rate-limit output, and this uses a single static rate limiter so
  it limits the overall rate across all cs_dsp log messages. The KUnit
  test can redirect it to change the suppression behavior.

- The cs_dsp debug message macros are changed to only call the dev_xxx()
  if cs_dsp_can_emit_message() returns true. These are still macros so
  there is no problem wrapping the dev_xxx(). For a normal not-KUnit
  build cs_dsp_can_emit_message() always returns true so these macros
  simplify down to being identical to calling dev_xxx() directly.

- The KUnit tests that cause a lot of cs_dsp messages now redirect
  cs_dsp_can_emit_message() to a local function. This returns false
  to suppress cs_dsp messages, unless DEBUG is defined for that test.

I have checked that for a x86_64 production (non-KUnit) build the
disassembled cs_dsp.o is identical to what was generated from the
original code. So the complier is correctly simplifying the
cs_dsp_can_emit_message() and macros down to only the call to dev_xxx().

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260310130343.1791951-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Most of the test suites perform a large number of test cases, so
mark the suites as KUNIT_SPEED_SLOW for anyone who finds that useful.

The callback test suites haven't been marked because they don't
perform many test cases, and the tests are quick.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260225125644.1248826-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

ASoC: Updates for v7.0

This release is almost all abut driers, there's very little core work
here, although some of that driver work is in more generic areas like
SDCA and SOF:

 - Generic SDCA support for reporting jack events.
 - Continuing platform support, cleanup and feature improements for the
   AMD, Intel, Qualcomm and SOF code.
 - Platform description improvements for the Cirrus drivers.
 - Support for NXP i.MX952, Realtek RT1320 and RT5575, and Sophogo
   CV1800B.

We also pulled in one small SPI API update and some more substantial
regmap work (cache description improvements) for use in drivers.

Use the dev_*_ratelimit() macros if the cs_dsp KUnit tests are enabled
in the build, and allow the KUnit tests to disable message output.

Some of the KUnit tests cause a very large number of log messages from
cs_dsp, because the tests perform many different test cases. This could
cause some lines to be dropped from the kernel log. Dropped lines can
prevent the KUnit wrappers from parsing the ktap output in the dmesg log.

The KUnit builds of cs_dsp export three bools that the KUnit tests can
use to entirely disable log output of err, warn and info messages. Some
tests have been updated to use this, replacing the previous fudge of a
usleep() in the exit handler of each test. We don't necessarily want to
disable all log messages if they aren't expected to be excessive,
so the rate-limiting allows leaving some logging enabled.

The rate-limited macros are not used in normal builds because it is not
appropriate to rate-limit every message. That could cause important
messages to be dropped, and there wouldn't be such a high rate of
messages in normal operation.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reported-by: Mark Brown <broonie@kernel.org>
Closes: https://lore.kernel.org/linux-sound/af393f08-facb-4c44-a054-1f61254803ec@opensource.cirrus.com/T/#t
Fixes: cd8c058499b6 ("firmware: cs_dsp: Add KUnit testing of bin error cases")
Link: https://patch.msgid.link/20260130171256.863152-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Add test cases for using the new long-offset block types to patch
memory that is >0xffff from the algorithm base.

This is just adding entries to the parameter data that have larger
offset values.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251231172711.450024-9-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Run the patch block test cases using the new long-offset block type.

This adds a new set of parameterization that uses
cs_dsp_mock_bin_add_patch_off32() to create the patch blocks in the
test bin file.

The test cases for Halo Core with V3 file format include another
run of the tests with the new parameterization, so that the tests
are run on the standard blocks and the long-offset blocks.

This commit does not add any new cases for offsets > 0xffff.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251231172711.450024-8-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Increase the size of the XM and YM regions in the mock Halo Core
register map for testing patch blocks with 32-bit offsets.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251231172711.450024-7-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Add cs_dsp_mock_bin_add_patch_off32(). This is the same as
cs_dsp_mock_bin_add_patch() except that it puts the offset in the
new 32-bit offset field and modifies the block type to indicate
that it uses the long offset.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251231172711.450024-6-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Add an argument to cs_dsp_mock_bin_add_raw_block() to pass a 32-bit
offset, and change the type of the existing offset argument to u16.

The cs_dsp_test_bin_error.c test uses cs_dsp_mock_bin_add_raw_block()
so it needs corresponding updates to pass 0 as the 32-bit offset.

Version 1 and 2 of the bin file format had a 16-bit offset on blocks
and the sample rate field of the blocks was not used. Version 3 adds
new block types that change the old sample rate field to be a 32-bit
offset with the old offset currently unused.

cs_dsp_mock_bin_add_raw_block() doesn't attempt to do any magic - its
purpose is to create a raw block exactly as specified by the calling
test code. So the test case can pass a value for both offset fields.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251231172711.450024-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Make the call to cs_dsp_mock_bin_add_patch() a function pointer in
the test case parameters, instead of calling it directly.

This is to allow for future parameterization by which function to
call to add a patch.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251231172711.450024-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>