Merge drm/drm-fixes into drm-misc-fixes

Backmerging to get updates from v6.15-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Merge branch 'next' into for-linus

Prepare input updates for 6.15 merge window.

Merge tag 'v6.14-rc4' into next

Sync up with the mainline.

Merge tag 'v6.14-rc1' into perf-tools-next

To get the various fixes in the current master.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>

Merge drm/drm-next into drm-xe-next

Sync to fix conlicts between drm-xe-next and drm-intel-next.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

Merge drm/drm-next into drm-misc-next

Bring rc1 to start the new release dev.

Signed-off-by: Maxime Ripard <mripard@kernel.org>

Merge drm/drm-next into drm-intel-next

Sync with v6.14-rc1.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Merge drm/drm-next into drm-intel-gt-next

We need
4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with a scope")
in order to land a i915 PMU simplification and a fix. That landed in 6.12
and

Merge drm/drm-next into drm-intel-gt-next

We need
4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with a scope")
in order to land a i915 PMU simplification and a fix. That landed in 6.12
and we are stuck at 6.9 so lets bump things forward.

Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>

show more ...

Merge branch 'for-6.15/amd_sfh' into for-linus

From: Mario Limonciello <mario.limonciello@amd.com>

Some platforms include a human presence detection (HPD) sensor. When
enabled and a user is detecte

Merge branch 'for-6.15/amd_sfh' into for-linus

From: Mario Limonciello <mario.limonciello@amd.com>

Some platforms include a human presence detection (HPD) sensor. When
enabled and a user is detected a wake event will be emitted from the
sensor fusion hub that software can react to.

Example use cases are "wake from suspend on approach" or to "lock
when leaving".

This is currently enabled by default on supported systems, but users
can't control it. This essentially means that wake on approach is
enabled which is a really surprising behavior to users that don't
expect it.

Instead of defaulting to enabled add a sysfs knob that users can
use to enable the feature if desirable and set it to disabled by
default.

show more ...

Merge tag 'sound-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound updates from Takashi Iwai:
"This was a relatively calm cycle, and most of changes are rather small

Merge tag 'sound-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound updates from Takashi Iwai:
"This was a relatively calm cycle, and most of changes are rather small
device-specific fixes. Here are highlights:

Core:
- Further enhancements of ALSA rawmidi and sequencer APIs for MIDI
2.0
- compress-offload API extensions for ASRC support

ASoC:
- Allow clocking on each DAI in an audio graph card to be configured
separately
- Improved power management for Renesas RZ-SSI
- KUnit testing for the Cirrus DSP framework
- Memory to meory operation support for Freescale/NXP platforms
- Support for pause operations in SOF
- Support for Allwinner suinv F1C100s, Awinc AW88083, Realtek
ALC5682I-VE

HD- and USB-audio:
- Add support for Focusrite Scarlett 4th Gen 16i16, 18i16, and 18i20
interfaces via new FCP driver
- TAS2781 SPI HD-audio sub-codec support
- Various device-specific quirks as usual"

* tag 'sound-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (235 commits)
ALSA: hda: tas2781-spi: Fix bogus error handling in tas2781_hda_spi_probe()
ALSA: hda: tas2781-spi: Fix error code in tas2781_read_acpi()
ALSA: hda: tas2781-spi: Delete some dead code
ALSA: usb: fcp: Fix return code from poll ops
ALSA: usb: fcp: Fix incorrect resp->opcode retrieval
ALSA: usb: fcp: Fix meter_levels type to __le32
ALSA: hda/realtek: Enable Mute LED on HP Laptop 14s-fq1xxx
ALSA: hda: tas2781-spi: Fix -Wsometimes-uninitialized in tasdevice_spi_switch_book()
ALSA: ctxfi: Simplify dao_clear_{left,right}_input() functions
ALSA: hda: tas2781-spi: select CRC32 instead of CRC32_SARWATE
ALSA: usb: fcp: Fix hwdep read ops types
ALSA: scarlett2: Add device_setup option to use FCP driver
ALSA: FCP: Add Focusrite Control Protocol driver
ALSA: hda/tas2781: Add tas2781 hda SPI driver
ALSA: hda/realtek - Fixed headphone distorted sound on Acer Aspire A115-31 laptop
ASoC: xilinx: xlnx_spdif: Simpify using devm_clk_get_enabled()
ALSA: hda: Support for Ideapad hotkey mute LEDs
ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83JX, 83MC and 83NM
ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83LC
ASoC: dapm: add support for preparing streams
...

show more ...

Merge tag 'asoc-v6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Updates for v6.14

This was quite a quiet release for what I imagine are holiday related

Merge tag 'asoc-v6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Updates for v6.14

This was quite a quiet release for what I imagine are holiday related
reasons, the diffstat is dominated by some Cirrus Logic Kunit tests.
There's the usual mix of small improvements and fixes, plus a few new
drivers and features. The diffstat includes some DRM changes due to
work on HDMI audio.

- Allow clocking on each DAI in an audio graph card to be configured
separately.
- Improved power management for Renesas RZ-SSI.
- KUnit testing for the Cirrus DSP framework.
- Memory to meory operation support for Freescale/NXP platforms.
- Support for pause operations in SOF.
- Support for Allwinner suinv F1C100s, Awinc AW88083, Realtek
ALC5682I-VE

show more ...

firmware: cirrus: Add KUnit tests for cs_dsp

Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:

This series adds KUnit tests for the cs_dsp module.

Most of the functionality in cs_ds

firmware: cirrus: Add KUnit tests for cs_dsp

Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:

This series adds KUnit tests for the cs_dsp module.

Most of the functionality in cs_dsp is for downloading firmware to
DSP memory and interacting with "control" words defined in that
memory. This doesn't require any emulation of running firmware,
because it is only reading and writing registers. So the testing can
be done using a dummy regmap. The way this is used to perform testing
is described in more detail in the commit message for each test.

ADSP1 is not tested because this was only used by the WM2200 codec,
a long-obsolete part that was discontinued in 2015.

show more ...

firmware: cs_dsp: Add KUnit testing of client callbacks

Test that the cs_dsp_client_ops callbacks are called when expected.

pre_run, post_run - when cs_dsp_run() is called.
pre_stop, post_stop - wh

firmware: cs_dsp: Add KUnit testing of client callbacks

Test that the cs_dsp_client_ops callbacks are called when expected.

pre_run, post_run - when cs_dsp_run() is called.
pre_stop, post_stop - when cs_dsp_stop() is called
control_add - when a WMFW is loaded
control_remove - when cs_dsp_remove() is called

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

show more ...

firmware: cs_dsp: Add KUnit testing of wmfw error cases

Add tests for various types of errors and illegal values in
wmfw files. This covers buffer overflows as well as general
unsupported field valu

firmware: cs_dsp: Add KUnit testing of wmfw error cases

Add tests for various types of errors and illegal values in
wmfw files. This covers buffer overflows as well as general
unsupported field values.

There are several sets of test cases to cover various different
versions of the wmfw file format.

V0 format was only used on the earlier ADSP2 devices. It does
not have algorithm blocks.

V1 format is used on all ADSP2 versions. It added algorithm
blocks and firmware coefficient descriptor blocks. Strings
are stored in fixed-length arrays.

V2 format is used on all ADSP2 versions. It is similar to V1
but space for strings is variable-length with either an 8-bit
or 16-bit length field.

V3 format is used on Halo Core DSPs and is mostly identical to
the V3 format.

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

show more ...

firmware: cs_dsp: Add KUnit testing of bin error cases

Add tests for various types of errors and illegal values in
bin files. This covers buffer overflows as well as general
unsupported field values

firmware: cs_dsp: Add KUnit testing of bin error cases

Add tests for various types of errors and illegal values in
bin files. This covers buffer overflows as well as general
unsupported field values.

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

show more ...

firmware: cs_dsp: Add KUnit testing of control read/write

Add KUnit test cases for control read/write.

Tests cases cover general reading and writing of controls:
1) Read/write at offset position in

firmware: cs_dsp: Add KUnit testing of control read/write

Add KUnit test cases for control read/write.

Tests cases cover general reading and writing of controls:
1) Read/write at offset position in control.
2) Read/write of various lengths less than length of the control.
3) Rejecting illegal arguments.

The test cases are run for ADSP2 with 16-bit registers, ADSP2
with 32-bit registers and Halo Core with 32-bit registers. The
ADSP2 cases are further divided into runs for V1 and V2 format
WMFW files, because there are differences in how V1 and V2
defines controls.

The obsolete V0 format does not have controls, so no testing of
that format is needed.

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

show more ...

firmware: cs_dsp: Add KUnit testing of control cache

Add KUnit test cases for the caching of control content.

The test cases can be divided into four groups:
1) The cache is correctly initialized w

firmware: cs_dsp: Add KUnit testing of control cache

Add KUnit test cases for the caching of control content.

The test cases can be divided into four groups:
1) The cache is correctly initialized when the firmware is first
downloaded.
2) Reads return the correct data.
3) Writes update the registers and cache.
4) If a value has been written to the control it is retained in
the cache and written out to the registers when the firmware
is started.

There are multiple test suites to cover:
- V1 and V2 format files on 16-bit and 32-bit ADSP2.
- V3 format files on Halo Core DSPs.

V1 format files, and some V2 format files, didn't provide access
flags for the controls. There are a couple of test cases for
unspecified flags to ensure backwards compatibility with the
original implementation of these older firmware versions.

The obsolete V0 format does not have controls, so no testing of
that format is needed.

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

show more ...

firmware: cs_dsp: Add KUnit testing of control parsing

Add KUnit test cases for parsing of firmware controls out of the
wmfw. These test cases are only testing that the data in the wmfw
is correctly

firmware: cs_dsp: Add KUnit testing of control parsing

Add KUnit test cases for parsing of firmware controls out of the
wmfw. These test cases are only testing that the data in the wmfw
is correctly interpreted and entered into the list of controls.

The test cases can be roughly divided into three types:
1) The correct values are extracted from the wmfw.
2) Variable-length strings are handled correctly.
3) Controls are correctly identified as unique or identical.

There are multiple test suites to cover:
- V1 and V2 format files on 16-bit and 32-bit ADSP2.
- V3 format files on Halo Core DSPs.

V1 format does not have named controls, and the strings in the
coefficient descriptor are fixed-length fields. On V2 and V3 format
the controls are named and all strings are variable-length.

The obsolete V0 format does not have controls, so no testing of
that format is needed.

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

show more ...

firmware: cs_dsp: Add KUnit testing of wmfw download

This adds a KUnit test suite to test downloading wmfw files.

The general technique is
1. Create mock wmfw file content
2. Tell cs_dsp to downloa

firmware: cs_dsp: Add KUnit testing of wmfw download

This adds a KUnit test suite to test downloading wmfw files.

The general technique is
1. Create mock wmfw file content
2. Tell cs_dsp to download the wmfw 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. In
addition to this there are 4 versions of the wmfw file format to be
tested.

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 <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-7-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

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 <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-6-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...

firmware: cs_dsp: Add mock bin file generator for KUnit testing

Add a mock firmware file that emulates what the firmware build tools
would normally create. This will be used by KUnit tests to genera

firmware: cs_dsp: Add mock bin file generator for KUnit testing

Add a mock firmware file that emulates what the firmware build tools
would normally create. This will be used by KUnit tests to generate a
test bin file.

The data payload in a bin is an opaque blob, so the mock bin only needs
to generate the appropriate file header and description block for each
payload blob.

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

show more ...

firmware: cs_dsp: Add mock wmfw file generator for KUnit testing

Add a mock firmware file that emulates what the firmware build tools
would normally create. This will be used by KUnit tests to gener

firmware: cs_dsp: Add mock wmfw file generator for KUnit testing

Add a mock firmware file that emulates what the firmware build tools
would normally create. This will be used by KUnit tests to generate a
test wmfw file.

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

show more ...

firmware: cs_dsp: Add mock DSP memory map for KUnit testing

Add helper functions to implement an emulation of the DSP memory map.

There are three main groups of functionality:

1. Define a mock cs_

firmware: cs_dsp: Add mock DSP memory map for KUnit testing

Add helper functions to implement an emulation of the DSP memory map.

There are three main groups of functionality:

1. Define a mock cs_dsp_region table.
2. Calculate the addresses of memory and algorithms from the firmware
header in XM.
3. Build a mock XM header in emulated XM.

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

show more ...

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 <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...