March 2024 - Alsa-devel - mailman.alsa-project.org

[RESEND PATCH v2] drm/bridge: dw-hdmi-i2s: set insert_pcuv bit if hardware supports it
by Geraldo Nascimento 14 Sep '24

14 Sep '24

Hi Mark, resending this as it failed to apply in my last submission. Added Neil Armstrong to Cc: as hopefully he will be able to better review this. Thanks, Geraldo Nascimento --- Starting with version 2.10a of Synopsys DesignWare HDMI controller the insert_pcuv bit was introduced. On RK3399pro SoM (Radxa Rock Pi N10), for example, if we neglect to set this bit and proceed to enable hdmi_sound and i2s2 on the device tree there will be extreme clipping of sound output, to the point that music sounds like white noise. Problem could also manifest as just mild cracking depending of HDMI audio implementation of sink. Setting insert_pcuv bit (bit 2 of aud_conf2 Audio Sample register) fixes this. Signed-off-by: Geraldo Nascimento <geraldogabriel(a)gmail.com> --- v1->v2: SoC->SoM on description, better commenting, minor style changes, conditional application of fix for L-PCM only --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio-20221017.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio-20221017.c @@ -42,6 +42,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data, struct dw_hdmi *hdmi = audio->hdmi; u8 conf0 = 0; u8 conf1 = 0; + u8 conf2 = 0; u8 inputclkfs = 0; /* it cares I2S only */ @@ -101,6 +102,28 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data, return -EINVAL; } + /* + * dw-hdmi introduced insert_pcuv bit in + * version 2.10a. + * + * This single bit (bit 2 of HDMI_AUD_CONF2) + * when set to 1 will enable the insertion of the PCUV + * (Parity, Channel Status, User bit and Validity) + * bits on the incoming audio stream. + * + * Support is limited to Linear PCM audio. If + * neglected, the lack of valid PCUV bits + * on L-PCM streams will cause anything from + * mild cracking to full blown extreme + * clipping depending on the HDMI audio + * implementation of the sink. + * + */ + + if (hdmi_read(audio, HDMI_DESIGN_ID) >= 0x21 && + !(hparms->iec.status[0] & IEC958_AES0_NONAUDIO)) + conf2 = HDMI_AUD_CONF2_INSERT_PCUV; + dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate); dw_hdmi_set_channel_status(hdmi, hparms->iec.status); dw_hdmi_set_channel_count(hdmi, hparms->channels); @@ -109,6 +120,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data, hdmi_write(audio, inputclkfs, HDMI_AUD_INPUTCLKFS); hdmi_write(audio, conf0, HDMI_AUD_CONF0); hdmi_write(audio, conf1, HDMI_AUD_CONF1); + hdmi_write(audio, conf2, HDMI_AUD_CONF2); return 0; } --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-20221017.h +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-20221017.h @@ -931,6 +931,11 @@ enum { HDMI_AUD_CONF1_WIDTH_16 = 0x10, HDMI_AUD_CONF1_WIDTH_24 = 0x18, +/* AUD_CONF2 field values */ + HDMI_AUD_CONF2_HBR = 0x01, + HDMI_AUD_CONF2_NLPCM = 0x02, + HDMI_AUD_CONF2_INSERT_PCUV = 0x04, + /* AUD_CTS3 field values */ HDMI_AUD_CTS3_N_SHIFT_OFFSET = 5, HDMI_AUD_CTS3_N_SHIFT_MASK = 0xe0,

3 3

[RFC PATCH 00/16] soundwire/ASoC: speed-up downloads with BTP/BRA protocol
by Pierre-Louis Bossart 20 Aug '24

20 Aug '24

This RFC patchset suggests a new API for ASoC codec drivers to use for firmware/table downloads. Problem statement: All existing transfers initiated by codec drivers rely on SoundWire read/write commands, which can only support ONE byte per frame. With the typical 48kHz frame rate, this means 384 kbits/s. In addition, the command/control is typically handled with a FIFO and interrupts which adds more software overhead. To give a practical reference, sending 32Kb takes 2.5s on Intel platforms, which means about 105kbit/s only. Additional non-audio activity is likely to adversely impact interrupt scheduling and further decrease the transfer speeds. New SDCA-based codecs have a need to download tables and DSP firmware which are typically between 20 and 256 Kb. The slow bus operation has a direct impact on boot/resume times, and clearly having to wait more than 300ms is a showstopper in terms of latency requirements and user-experience. Suggested solution: The MIPI specification and most of the new codecs support the Bulk Transfer Protocol (BTP) and specifically the Bulk Register Access (BRA) configuration. This mode reclaims the 'audio' data space of the SoundWire frame to send firmware/coefficients over the DataPort 0 (DP0). The API suggested is rather simple, with the following sequence expected: open(): reserve resources and prepare hardware send_async(): trigger DMAs and perform SoundWire bank switch wait(): wait for DMA completion and disable DMAs close(): release resources Benefits: Even after accounting for the protocol overhead, the data can be sent 8x or 16x faster on the link than with the regular commands. With the use of DMAs, the software overhead becomes limited to the initialization. Measured results show that transferring the same 32Kb takes about 100ms, a 25x improvement on the baseline write() commands with an actual bitrate of 2.6 Mbits/s. These results are a measure of bus/hardware performance mainly, and will typically not be too modified by the CPU activity and scheduling. The performance for reads is similar, with a 25x speedup measured. Limitations: Setting up the transfers over DP0 takes time, and the reliance on DMAs on the host side brings alignment restrictions. The BTP/BRA protocol is really only relevant for "large" transfers done during boot/resume *before* audio transfers take place. Mixing BTP/BRA and audio is a nightmare, this patchset suggests a mutual-exclusion between two usages. Scope: This patchset only exposes the API and a debugfs interface to initiate commands, validate results and measure performance. The actual use of the API is left as an exercise for codec driver developers. This patchset depends on a number of pre-requisite patches and will not build on top of any for-next branches. The main intent of this RFC is to gather comments on the usage, API, benefits and restrictions. The code and functionality was tested on an Intel LunarLake RVP platform connected to a Realtek RT711-SDCA device. Acknowledgements: Thanks to Zeek Tsai at Realtek for providing test sequences that helped reconcile the data formatted by the host driver with the expected results on the code side. Pierre-Louis Bossart (16): Documentation: driver: add SoundWire BRA description soundwire: cadence: add BTP support for DP0 soundwire: stream: extend sdw_alloc_stream() to take 'type' parameter soundwire: extend sdw_stream_type to BPT soundwire: stream: special-case the bus compute_params() routine soundwire: stream: reuse existing code for BPT stream soundwire: bus: add API for BPT protocol soundwire: bus: add bpt_stream pointer soundwire: crc8: add constant table soundwire: cadence: add BTP/BRA helpers to format data soundwire: intel_auxdevice: add indirection for BPT open/close/send_async/wait ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMA soundwire: intel: add BPT context definition soundwire: intel_ace2x: add BPT open/close/send_async/wait soundwire: debugfs: add interface for BPT/BRA transfers ASoC: rt711-sdca: add DP0 support Documentation/driver-api/soundwire/bra.rst | 478 +++++++++++++ Documentation/driver-api/soundwire/index.rst | 1 + Documentation/driver-api/soundwire/stream.rst | 2 +- .../driver-api/soundwire/summary.rst | 5 +- drivers/soundwire/Kconfig | 1 + drivers/soundwire/Makefile | 4 +- drivers/soundwire/amd_manager.c | 2 +- drivers/soundwire/bus.c | 77 +++ drivers/soundwire/bus.h | 18 + drivers/soundwire/cadence_master.c | 646 +++++++++++++++++- drivers/soundwire/cadence_master.h | 30 + drivers/soundwire/crc8.c | 277 ++++++++ drivers/soundwire/crc8.h | 11 + drivers/soundwire/debugfs.c | 122 +++- .../soundwire/generic_bandwidth_allocation.c | 84 ++- drivers/soundwire/intel.h | 12 + drivers/soundwire/intel_ace2x.c | 377 ++++++++++ drivers/soundwire/intel_auxdevice.c | 55 ++ drivers/soundwire/qcom.c | 2 +- drivers/soundwire/stream.c | 137 +++- include/linux/soundwire/sdw.h | 91 ++- include/linux/soundwire/sdw_intel.h | 16 + include/sound/hda-sdw-bpt.h | 76 +++ sound/soc/codecs/rt711-sdca-sdw.c | 8 + sound/soc/qcom/sdw.c | 2 +- sound/soc/sof/intel/Kconfig | 8 +- sound/soc/sof/intel/Makefile | 4 + sound/soc/sof/intel/hda-sdw-bpt.c | 328 +++++++++ 28 files changed, 2810 insertions(+), 64 deletions(-) create mode 100644 Documentation/driver-api/soundwire/bra.rst create mode 100644 drivers/soundwire/crc8.c create mode 100644 drivers/soundwire/crc8.h create mode 100644 include/sound/hda-sdw-bpt.h create mode 100644 sound/soc/sof/intel/hda-sdw-bpt.c -- 2.39.2

4 60

[PATCH v11 00/10] spi: Add support for stacked/parallel memories
by Amit Kumar Mahapatra 19 Aug '24

19 Aug '24

This patch series updated the spi-nor, spi core and the AMD-Xilinx GQSPI driver to add stacked and parallel memories support. The first nine patches https://lore.kernel.org/all/20230119185342.2093323-1-amit.kumar-mahapatra@a… https://lore.kernel.org/all/20230310173217.3429788-2-amit.kumar-mahapatra@a… https://lore.kernel.org/all/20230310173217.3429788-3-amit.kumar-mahapatra@a… https://lore.kernel.org/all/20230310173217.3429788-4-amit.kumar-mahapatra@a… https://lore.kernel.org/all/20230310173217.3429788-5-amit.kumar-mahapatra@a… https://lore.kernel.org/all/20230310173217.3429788-6-amit.kumar-mahapatra@a… https://lore.kernel.org/all/20230310173217.3429788-7-amit.kumar-mahapatra@a… https://lore.kernel.org/all/20230310173217.3429788-8-amit.kumar-mahapatra@a… https://lore.kernel.org/all/20230310173217.3429788-9-amit.kumar-mahapatra@a… of the previous series got applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next But the rest of the patches in the series did not get applied as failure was reported for spi driver with GPIO CS, so send the remaining patches in the series after rebasing it on top of for-next branch and fixing the issue. CS GPIO is not tested on our hardware, but it has been tested by @Stefan https://lore.kernel.org/all/005001da1efc$619ad5a0$24d080e0$@opensource.cirr… --- BRANCH: for-next Changes in v11: - Rebased patch series on top of latest for-next branch. - Added a new patch(1/10) to replace spi->chip_select with spi_get_chipselect() call in tps6594-spi.c. - Added a new patch(2/10) to replace spi->chip_select with spi_get_chipseletc() call in cs35l56_hda_spi.c. - In spi.c initialized unused CS[] to 0xff and spi->cs_index_mask to 0x01 in all flows. - Updated spi_dev_check() to compare the CS of old spi device with the new spi device CS. - Updated cover letter description to add information regarding GPIO CS testing and added Stefen's Tested-by tag in 3/10 patch. Changes in v10: - Rebased patch series on top of latest for-next branch and fixed merge conflicts. Changes in v9: - Updated 1/8 patch description to add an high-level overview of parallel(multi-cs) & stacked design. - Initialized all unused CS to 0xFF. - Moved CS check from spi_add_device() to __spi_add_device(). - Updated __spi_add_device() to check to make sure that multiple logical CS don't map to the same physical CS and same physical CS doesn't map to different logical CS. - Updated 1/8, 5/8 & 7/8 to support arbitrary number of flash devices connected in parallel or stacked mode. - Updated documentation for chip_select. - Added a new spi-nor structure member nor->num_flash to keep track of the number of flashes connected. - Added a new patch in the series 4/8 to move write_enable call just before spi_mem ops call in SPI-NOR. - Added comments in SPI core & SPI-NOR. - Rebased the patch series on top of the latest for-next branch. Changes in v8: - Updated __spi_add_device() and spi_set_cs() to fix spi driver failure with GPIO CS. - Rebased the patch series on top of latest for-next branch and fixed merge conflicts. - Updated cover letter description to add information regarding GPIO CS testing and request Stefan to provide his Tested-by tag for 1/7 patch. - Updated 1/7 patch description. Changes in v7: - Updated spi_dev_check() to avoid failures for spi driver GPIO CS and moved the error message from __spi_add_device() to spi_dev_check(). - Resolved code indentation issue in spi_set_cs(). - In spi_set_cs() call spi_delay_exec( ) once if the controller supports multi cs with both the CS backed by GPIO. - Updated __spi_validate()to add checks for both the GPIO CS. - Replaced cs_index_mask bit mask with SPI_CS_CNT_MAX. - Updated struct spi_controller to represent multi CS capability of the spi controller through a flag bit SPI_CONTROLLER_MULTI_CS instead of a boolen structure member "multi_cs_cap". - Updated 1/7 patch description . Changes in v6: - Rebased on top of latest v6.3-rc1 and fixed merge conflicts in spi-mpc512x-psc.c, sfdp.c, spansion.c files and removed spi-omap-100k.c. - Updated spi_dev_check( ) to reject new devices if any one of the chipselect is used by another device. Changes in v5: - Rebased the patches on top of v6.3-rc1 and fixed the merge conflicts. - Fixed compilation warnings in spi-sh-msiof.c with shmobile_defconfig Changes in v4: - Fixed build error in spi-pl022.c file - reported by Mark. - Fixed build error in spi-sn-f-ospi.c file. - Added Reviewed-by: Serge Semin <fancer.lancer(a)gmail.com> tag. - Added two more patches to replace spi->chip_select with API calls in mpc832x_rdb.c & cs35l41_hda_spi.c files. Changes in v3: - Rebased the patches on top of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next - Added a patch to convert spi_nor_otp_region_len(nor) & spi_nor_otp_n_regions(nor) macros into inline functions - Added Reviewed-by & Acked-by tags Changes in v2: - Rebased the patches on top of v6.2-rc1 - Created separate patch to add get & set APIs for spi->chip_select & spi->cs_gpiod, and replaced all spi->chip_select and spi->cs_gpiod references with the API calls. - Created separate patch to add get & set APIs for nor->params. --- Amit Kumar Mahapatra (10): mfd: tps6594: Use set/get APIs to access spi->chip_select ALSA: hda/cs35l56: Use set/get APIs to access spi->chip_select spi: Add multi-cs memories support in SPI core mtd: spi-nor: Convert macros with inline functions mtd: spi-nor: Add APIs to set/get nor->params mtd: spi-nor: Move write enable inside specific write & erase APIs mtd: spi-nor: Add stacked memories support in spi-nor spi: spi-zynqmp-gqspi: Add stacked memories support in GQSPI driver mtd: spi-nor: Add parallel memories support in spi-nor spi: spi-zynqmp-gqspi: Add parallel memories support in GQSPI driver drivers/mfd/tps6594-spi.c | 2 +- drivers/mtd/spi-nor/atmel.c | 17 +- drivers/mtd/spi-nor/core.c | 683 +++++++++++++++++++++++++------ drivers/mtd/spi-nor/core.h | 8 + drivers/mtd/spi-nor/debugfs.c | 4 +- drivers/mtd/spi-nor/gigadevice.c | 4 +- drivers/mtd/spi-nor/issi.c | 11 +- drivers/mtd/spi-nor/macronix.c | 10 +- drivers/mtd/spi-nor/micron-st.c | 35 +- drivers/mtd/spi-nor/otp.c | 48 ++- drivers/mtd/spi-nor/sfdp.c | 33 +- drivers/mtd/spi-nor/spansion.c | 57 +-- drivers/mtd/spi-nor/sst.c | 7 +- drivers/mtd/spi-nor/swp.c | 25 +- drivers/mtd/spi-nor/winbond.c | 2 +- drivers/mtd/spi-nor/xilinx.c | 18 +- drivers/spi/spi-zynqmp-gqspi.c | 58 ++- drivers/spi/spi.c | 259 ++++++++++-- include/linux/mtd/spi-nor.h | 21 +- include/linux/spi/spi.h | 51 ++- sound/pci/hda/cs35l56_hda_spi.c | 2 +- 21 files changed, 1085 insertions(+), 270 deletions(-) -- 2.17.1

10 61

[alsa-devel] unsupported variant of snd_hda_intel
by Alexandre 04 Jul '24

04 Jul '24

Hello, I have an Acer Aspire 4736G laptop. The soundcard that is shipped in this laptop is intel-hda based as shown (actually it's a realtek): cat /proc/asound/cards 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0x9b300000 irq 46 Basic sound output is correct but few feature are missing: - internal mic seems to be found but do not works. - sound output stop working when trying to send it using HDMI output - heads do not work when plugged neither when forcing pulseaudio to use it. I have an ubuntu 10.10 which is shipped with alsa 1.0.23. I have googled around and tried loading the snd-hda-intel with several parameters () as found in HD-Audio-Models.txt to no avail. cat /proc/asound/pcm 00-00: ALC888 Analog : ALC888 Analog : playback 1 : capture 1 00-01: ALC888 Digital : ALC888 Digital : playback 1 00-03: NVIDIA HDMI : NVIDIA HDMI : playback 1 Where can I begin to help implement the support for this sound card? I have very skills in developement in general but am ready to try if it is not to hard (I supose I can use previous code for similar models).. I just need a shepherd. Thanks

4 4

ALSA 1.2.8 release
by Jaroslav Kysela 11 Jun '24

11 Jun '24

Hello all, new ALSA userspace packages were released. You may download them from the ALSA website http://www.alsa-project.org or directly: HTTP: https://www.alsa-project.org/files/pub FTP: ftp://ftp.alsa-project.org/pub Released packages: alsa-lib alsa-utils alsa-ucm-conf tinycompress Full list of changes: https://www.alsa-project.org/wiki/Changes_v1.2.7.2_v1.2.8 The fingerprint of the public signing key is: F04D F507 37AC 1A88 4C4B 3D71 8380 596D A6E5 9C91 Have fun, Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

1 4

[PATCH v15 00/16] Add audio support in v4l2 framework
by Shengjiu Wang 27 May '24

27 May '24

Audio signal processing also has the requirement for memory to memory similar as Video. This asrc memory to memory (memory ->asrc->memory) case is a non real time use case. User fills the input buffer to the asrc module, after conversion, then asrc sends back the output buffer to user. So it is not a traditional ALSA playback and capture case. It is a specific use case, there is no reference in current kernel. v4l2 memory to memory is the closed implementation, v4l2 current support video, image, radio, tuner, touch devices, so it is not complicated to add support for this specific audio case. Because we had implemented the "memory -> asrc ->i2s device-> codec" use case in ALSA. Now the "memory->asrc->memory" needs to reuse the code in asrc driver, so the first 3 patches is for refining the code to make it can be shared by the "memory->asrc->memory" driver. The main change is in the v4l2 side, A /dev/vl4-audioX will be created, user applications only use the ioctl of v4l2 framework. Other change is to add memory to memory support for two kinds of i.MX ASRC module. changes in v15: - update MAINTAINERS for imx-asrc.c and vim2m-audio.c changes in v14: - document the reservation of 'AUXX' fourcc format. - add v4l2_audfmt_to_fourcc() definition. changes in v13 - change 'pixelformat' to 'audioformat' in dev-audio-mem2mem.rst - add more description for clock drift in ext-ctrls-audio-m2m.rst - Add "media: v4l2-ctrls: add support for fraction_bits" from Hans to avoid build issue for kernel test robot changes in v12 - minor changes according to comments - drop min_buffers_needed = 1 and V4L2_CTRL_FLAG_UPDATE flag - drop bus_info changes in v11 - add add-fixed-point-test-controls in vivid. - add v4l2_ctrl_fp_compose() helper function for min and max changes in v10 - remove FIXED_POINT type - change code base on media: v4l2-ctrls: add support for fraction_bits - fix issue reported by kernel test robot - remove module_alias changes in v9: - add MEDIA_ENT_F_PROC_AUDIO_RESAMPLER. - add MEDIA_INTF_T_V4L_AUDIO - add media controller support - refine the vim2m-audio to support 8k<->16k conversion. changes in v8: - refine V4L2_CAP_AUDIO_M2M to be 0x00000008 - update doc for FIXED_POINT - address comments for imx-asrc changes in v7: - add acked-by from Mark - separate commit for fixed point, m2m audio class, audio rate controls - use INTEGER_MENU for rate, FIXED_POINT for rate offset - remove used fmts - address other comments for Hans changes in v6: - use m2m_prepare/m2m_unprepare/m2m_start/m2m_stop to replace m2m_start_part_one/m2m_stop_part_one, m2m_start_part_two/m2m_stop_part_two. - change V4L2_CTRL_TYPE_ASRC_RATE to V4L2_CTRL_TYPE_FIXED_POINT - fix warning by kernel test rebot - remove some unused format V4L2_AUDIO_FMT_XX - Get SNDRV_PCM_FORMAT from V4L2_AUDIO_FMT in driver. - rename audm2m to viaudm2m. changes in v5: - remove V4L2_AUDIO_FMT_LPCM - define audio pixel format like V4L2_AUDIO_FMT_S8... - remove rate and format in struct v4l2_audio_format. - Add V4L2_CID_ASRC_SOURCE_RATE and V4L2_CID_ASRC_DEST_RATE controls - updata document accordingly. changes in v4: - update document style - separate V4L2_AUDIO_FMT_LPCM and V4L2_CAP_AUDIO_M2M in separate commit changes in v3: - Modify documents for adding audio m2m support - Add audio virtual m2m driver - Defined V4L2_AUDIO_FMT_LPCM format type for audio. - Defined V4L2_CAP_AUDIO_M2M capability type for audio m2m case. - with modification in v4l-utils, pass v4l2-compliance test. changes in v2: - decouple the implementation in v4l2 and ALSA - implement the memory to memory driver as a platfrom driver and move it to driver/media - move fsl_asrc_common.h to include/sound folder Hans Verkuil (1): media: v4l2-ctrls: add support for fraction_bits Shengjiu Wang (15): ASoC: fsl_asrc: define functions for memory to memory usage ASoC: fsl_easrc: define functions for memory to memory usage ASoC: fsl_asrc: move fsl_asrc_common.h to include/sound ASoC: fsl_asrc: register m2m platform device ASoC: fsl_easrc: register m2m platform device media: uapi: Add V4L2_CAP_AUDIO_M2M capability flag media: v4l2: Add audio capture and output support media: uapi: Define audio sample format fourcc type media: uapi: Add V4L2_CTRL_CLASS_M2M_AUDIO media: uapi: Add audio rate controls support media: uapi: Declare interface types for Audio media: uapi: Add an entity type for audio resampler media: vivid: add fixed point test controls media: imx-asrc: Add memory to memory driver media: vim2m-audio: add virtual driver for audio memory to memory .../media/mediactl/media-types.rst | 11 + .../userspace-api/media/v4l/buffer.rst | 6 + .../userspace-api/media/v4l/common.rst | 1 + .../media/v4l/dev-audio-mem2mem.rst | 71 + .../userspace-api/media/v4l/devices.rst | 1 + .../media/v4l/ext-ctrls-audio-m2m.rst | 59 + .../userspace-api/media/v4l/pixfmt-audio.rst | 100 ++ .../userspace-api/media/v4l/pixfmt.rst | 1 + .../media/v4l/vidioc-enum-fmt.rst | 2 + .../media/v4l/vidioc-g-ext-ctrls.rst | 4 + .../userspace-api/media/v4l/vidioc-g-fmt.rst | 4 + .../media/v4l/vidioc-querycap.rst | 3 + .../media/v4l/vidioc-queryctrl.rst | 11 +- .../media/videodev2.h.rst.exceptions | 3 + MAINTAINERS | 17 + .../media/common/videobuf2/videobuf2-v4l2.c | 4 + drivers/media/platform/nxp/Kconfig | 13 + drivers/media/platform/nxp/Makefile | 1 + drivers/media/platform/nxp/imx-asrc.c | 1256 +++++++++++++++++ drivers/media/test-drivers/Kconfig | 10 + drivers/media/test-drivers/Makefile | 1 + drivers/media/test-drivers/vim2m-audio.c | 793 +++++++++++ drivers/media/test-drivers/vivid/vivid-core.h | 2 + .../media/test-drivers/vivid/vivid-ctrls.c | 26 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 9 + drivers/media/v4l2-core/v4l2-ctrls-api.c | 1 + drivers/media/v4l2-core/v4l2-ctrls-core.c | 93 +- drivers/media/v4l2-core/v4l2-ctrls-defs.c | 10 + drivers/media/v4l2-core/v4l2-dev.c | 21 + drivers/media/v4l2-core/v4l2-ioctl.c | 66 + drivers/media/v4l2-core/v4l2-mem2mem.c | 13 +- include/media/v4l2-ctrls.h | 13 +- include/media/v4l2-dev.h | 2 + include/media/v4l2-ioctl.h | 34 + .../fsl => include/sound}/fsl_asrc_common.h | 60 + include/uapi/linux/media.h | 2 + include/uapi/linux/v4l2-controls.h | 9 + include/uapi/linux/videodev2.h | 50 +- sound/soc/fsl/fsl_asrc.c | 144 ++ sound/soc/fsl/fsl_asrc.h | 4 +- sound/soc/fsl/fsl_asrc_dma.c | 2 +- sound/soc/fsl/fsl_easrc.c | 233 +++ sound/soc/fsl/fsl_easrc.h | 6 +- 43 files changed, 3145 insertions(+), 27 deletions(-) create mode 100644 Documentation/userspace-api/media/v4l/dev-audio-mem2mem.rst create mode 100644 Documentation/userspace-api/media/v4l/ext-ctrls-audio-m2m.rst create mode 100644 Documentation/userspace-api/media/v4l/pixfmt-audio.rst create mode 100644 drivers/media/platform/nxp/imx-asrc.c create mode 100644 drivers/media/test-drivers/vim2m-audio.c rename {sound/soc/fsl => include/sound}/fsl_asrc_common.h (60%) -- 2.34.1

11 49

[PATCH 0/2][next] firewire: Avoid -Wflex-array-member-not-at-end warnings
by Gustavo A. R. Silva 29 Apr '24

29 Apr '24

-Wflex-array-member-not-at-end is coming in GCC-14, and we are getting ready to enable it globally. So, we are deprecating flexible-array members in the middle of another struct. There are currently a couple of local structures (`u` and `template`) that are using a flexible `struct fw_iso_packet` as header for a couple of on-stack arrays. We make use of the `struct_group_tagged()` helper to separate the flexible array from the rest of the members in the flexible structure, and, with this, we can now declare objects of the type of the tagged struct, without embedding the flexible array in the middle of another struct. We also use `container_of()` whenever we need to retrieve a pointer to the flexible structure, through which the flexible-array member can be accessed. With these changes, we fix a couple of -Wflex-array-member-not-at-end warnings. Gustavo A. R. Silva (2): firewire: Avoid -Wflex-array-member-not-at-end warning ALSA: firewire-lib: Avoid -Wflex-array-member-not-at-end warning drivers/firewire/core-cdev.c | 9 +++++---- include/linux/firewire.h | 16 +++++++++------- sound/firewire/amdtp-stream.c | 8 +++++--- 3 files changed, 19 insertions(+), 14 deletions(-) -- 2.34.1

4 7

[PATCH 0/3] sysfs: Group visibility fixups
by Dan Williams 29 Apr '24

29 Apr '24

Hey Greg, Marc was able to get me a backtrace for that bootup hang scenario that Pierre noted here [1]. A Tested-by is still pending, but I am certain this is the issue, and it may impact more than just the one platform if that "empty_attrs" pattern has been repeated anywhere else in the kernel. I also took some time to document how to use the helpers a bit better, and introduce DEFINE_SIMPLE_SYSFS_GROUP_VISIBLE() for cases where all that matters is group visibility and not per attribute visibility. [1]: http://lore.kernel.org/r/b93ec9c2-23f5-486b-a3dc-ed9b960df359@linux.intel.c… --- Dan Williams (3): sysfs: Fix crash on empty group attributes array sysfs: Document new "group visible" helpers sysfs: Introduce DEFINE_SIMPLE_SYSFS_GROUP_VISIBLE() fs/sysfs/group.c | 4 +- include/linux/sysfs.h | 85 +++++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 84 insertions(+), 5 deletions(-) base-commit: 70317fd24b419091aa0a6dc3ea3ec7bb50c37c32

4 18

[PATCH v2 00/25] virtio: store owner from modules with register_virtio_driver()
by Krzysztof Kozlowski 25 Apr '24

25 Apr '24

Changes in v2: - Three new patches: virtio mem+input+balloon - Minor commit msg adjustments - Add tags - Link to v1: https://lore.kernel.org/r/20240327-module-owner-virtio-v1-0-0feffab77d99@li… Merging ======= All further patches depend on the first virtio patch, therefore please ack and this should go via one tree: maybe virtio? Description =========== Modules registering driver with register_virtio_driver() often forget to set .owner field. Solve the problem by moving this task away from the drivers to the core virtio code, just like we did for platform_driver in commit 9447057eaff8 ("platform_device: use a macro instead of platform_driver_register"). Best regards, Krzysztof --- Krzysztof Kozlowski (25): virtio: store owner from modules with register_virtio_driver() virtio: balloon: drop owner assignment virtio: input: drop owner assignment virtio: mem: drop owner assignment um: virt-pci: drop owner assignment virtio_blk: drop owner assignment bluetooth: virtio: drop owner assignment hwrng: virtio: drop owner assignment virtio_console: drop owner assignment crypto: virtio - drop owner assignment firmware: arm_scmi: virtio: drop owner assignment gpio: virtio: drop owner assignment drm/virtio: drop owner assignment iommu: virtio: drop owner assignment misc: nsm: drop owner assignment net: caif: virtio: drop owner assignment net: virtio: drop owner assignment net: 9p: virtio: drop owner assignment vsock/virtio: drop owner assignment wifi: mac80211_hwsim: drop owner assignment nvdimm: virtio_pmem: drop owner assignment rpmsg: virtio: drop owner assignment scsi: virtio: drop owner assignment fuse: virtio: drop owner assignment sound: virtio: drop owner assignment Documentation/driver-api/virtio/writing_virtio_drivers.rst | 1 - arch/um/drivers/virt-pci.c | 1 - drivers/block/virtio_blk.c | 1 - drivers/bluetooth/virtio_bt.c | 1 - drivers/char/hw_random/virtio-rng.c | 1 - drivers/char/virtio_console.c | 2 -- drivers/crypto/virtio/virtio_crypto_core.c | 1 - drivers/firmware/arm_scmi/virtio.c | 1 - drivers/gpio/gpio-virtio.c | 1 - drivers/gpu/drm/virtio/virtgpu_drv.c | 1 - drivers/iommu/virtio-iommu.c | 1 - drivers/misc/nsm.c | 1 - drivers/net/caif/caif_virtio.c | 1 - drivers/net/virtio_net.c | 1 - drivers/net/wireless/virtual/mac80211_hwsim.c | 1 - drivers/nvdimm/virtio_pmem.c | 1 - drivers/rpmsg/virtio_rpmsg_bus.c | 1 - drivers/scsi/virtio_scsi.c | 1 - drivers/virtio/virtio.c | 6 ++++-- drivers/virtio/virtio_balloon.c | 1 - drivers/virtio/virtio_input.c | 1 - drivers/virtio/virtio_mem.c | 1 - fs/fuse/virtio_fs.c | 1 - include/linux/virtio.h | 7 +++++-- net/9p/trans_virtio.c | 1 - net/vmw_vsock/virtio_transport.c | 1 - sound/virtio/virtio_card.c | 1 - 27 files changed, 9 insertions(+), 30 deletions(-) --- base-commit: 7fdcff3312e16ba8d1419f8a18f465c5cc235ecf change-id: 20240327-module-owner-virtio-546763b3ca22 Best regards, -- Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>

12 40

[PATCH v9 00/13] Introduce STM32 Firewall framework
by Gatien Chevallier 24 Apr '24

24 Apr '24

Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers register to the framework to offer firewall services such as access granting. This series of patches is a new approach on the previous STM32 system bus, history is available here: https://lore.kernel.org/lkml/20230127164040.1047583/ The need for such framework arises from the fact that there are now multiple hardware firewalls implemented across multiple products. Drivers are shared between different products, using the same code. When it comes to firewalls, the purpose mostly stays the same: Protect hardware resources. But the implementation differs, and there are multiple types of firewalls: peripheral, memory, ... Some hardware firewall controllers such as the RIFSC implemented on STM32MP2x platforms may require to take ownership of a resource before being able to use it, hence the requirement for firewall services to take/release the ownership of such resources. On the other hand, hardware firewall configurations are becoming more and more complex. These mecanisms prevent platform crashes or other firewall-related incoveniences by denying access to some resources. The stm32 firewall framework offers an API that is defined in firewall controllers drivers to best fit the specificity of each firewall. For every peripherals protected by either the ETZPC or the RIFSC, the firewall framework checks the firewall controlelr registers to see if the peripheral's access is granted to the Linux kernel. If not, the peripheral is configured as secure, the node is marked populated, so that the driver is not probed for that device. The firewall framework relies on the access-controller device tree binding. It is used by peripherals to reference a domain access controller. In this case a firewall controller. The bus uses the ID referenced by the access-controller property to know where to look in the firewall to get the security configuration for the peripheral. This allows a device tree description rather than a hardcoded peripheral table in the bus driver. The STM32 ETZPC device is responsible for filtering accesses based on security level, or co-processor isolation for any resource connected to it. The RIFSC is responsible for filtering accesses based on Compartment ID / security level / privilege level for any resource connected to it. STM32MP13/15/25 SoC device tree files are updated in this series to implement this mecanism. Changes in V9: - Added Rob's reviews tags on bindings/of files - Added "simple-bus" to RIFSC/ETZPC compatible item list Changes in V8: - Add missing "simple-bus" compatible in STM32MP13/25 SoC device tree files for the ETZPC/RIFSC nodes - Add missing dependency on OF for OF_DYNAMIC that is selected by STM32_FIREWALL Changes in V7: - Separate indentation changes from access-controllers changes in the device tree file commits - Select OF_DYNAMIC when STM32_FIREWALL is set in order to use of_detach_node() in the firewall framework - Handle previously non-present RNG and HASH nodes in the STM32MP13 device tree file Changes in V6: - Rename access-controller to access-controllers - Remove access-controller-provider - Update device trees and other bindings accordingly - Rework ETZPC/RIFSC bindings to define what access-controllers cells contain inside #access-controller-cells - Some other minor fixes Changes in V5: - Integrate and rework the "feature-domains" binding patch in this patchset. The binding is renamed to "access-controller" - Rename every feature-domain* reference to access-control* ones - Correct loop bug and missing select STM32_FIREWALL in 32-bit platform Kconfig Changes in V4: - Fix typo in commit message and YAML check errors in "dt-bindings: Document common device controller bindings" Note: This patch should be ignored as stated in the cover letter. I've done this to avoid errors on this series of patch - Correct code syntax/style issues reported by Simon Horman - Added Jonathan's tag for IIO on the treewide patch Changes in V3: Change incorrect ordering for bindings commits leading to an error while running "make DT_CHECKER_FLAGS=-m dt_binding_check" Changes in V2: generic: - Add fw_devlink dependency for "feature-domains" property. bindings: - Corrected YAMLS errors highlighted by Rob's robot - Firewall controllers YAMLs no longer define the maxItems for the "feature-domains" property - Renamed st,stm32-rifsc.yaml to st,stm32mp25-rifsc.yaml - Fix examples in YAML files - Change feature-domains maxItems to 2 in firewall consumer files as there should not be more than 2 entries for now - Declare "feature-domain-names" as an optional property for firewall controllers child nodes. - Add missing "feature-domains" property declaration in bosch,m_can.yaml and st,stm32-cryp.yaml files firewall framework: - Support multiple entries for "feature-domains" property - Better handle the device-tree parsing using phandle+args APIs - Remove "resource firewall" type - Add a field for the name of the firewall entry - Fix licenses RIFSC: - Add controller name - Driver is now a module_platform_driver - Fix license ETZPC: - Add controller name - Driver is now a module_platform_driver - Fix license Device trees: - Fix rifsc node name - Move the "ranges" property under the "feature-domains" one Gatien Chevallier (12): dt-bindings: treewide: add access-controllers description dt-bindings: bus: document RIFSC dt-bindings: bus: document ETZPC firewall: introduce stm32_firewall framework of: property: fw_devlink: Add support for "access-controller" bus: rifsc: introduce RIFSC firewall controller driver arm64: dts: st: add RIFSC as an access controller for STM32MP25x boards bus: etzpc: introduce ETZPC firewall controller driver ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards ARM: dts: stm32: put ETZPC as an access controller for STM32MP15x boards ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards ARM: dts: stm32: put ETZPC as an access controller for STM32MP13x boards Oleksii Moisieiev (1): dt-bindings: document generic access controllers .../access-controllers.yaml | 84 + .../bindings/bus/st,stm32-etzpc.yaml | 96 + .../bindings/bus/st,stm32mp25-rifsc.yaml | 105 + .../bindings/crypto/st,stm32-cryp.yaml | 4 + .../bindings/crypto/st,stm32-hash.yaml | 4 + .../devicetree/bindings/dma/st,stm32-dma.yaml | 4 + .../bindings/dma/st,stm32-dmamux.yaml | 4 + .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 4 + .../bindings/iio/adc/st,stm32-adc.yaml | 4 + .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 4 + .../bindings/iio/dac/st,stm32-dac.yaml | 4 + .../bindings/media/cec/st,stm32-cec.yaml | 4 + .../bindings/media/st,stm32-dcmi.yaml | 4 + .../memory-controllers/st,stm32-fmc2-ebi.yaml | 4 + .../bindings/mfd/st,stm32-lptimer.yaml | 4 + .../bindings/mfd/st,stm32-timers.yaml | 4 + .../devicetree/bindings/mmc/arm,pl18x.yaml | 4 + .../bindings/net/can/bosch,m_can.yaml | 4 + .../devicetree/bindings/net/stm32-dwmac.yaml | 4 + .../bindings/phy/phy-stm32-usbphyc.yaml | 4 + .../bindings/regulator/st,stm32-vrefbuf.yaml | 4 + .../devicetree/bindings/rng/st,stm32-rng.yaml | 4 + .../bindings/serial/st,stm32-uart.yaml | 4 + .../bindings/sound/st,stm32-i2s.yaml | 4 + .../bindings/sound/st,stm32-sai.yaml | 4 + .../bindings/sound/st,stm32-spdifrx.yaml | 4 + .../bindings/spi/st,stm32-qspi.yaml | 4 + .../devicetree/bindings/spi/st,stm32-spi.yaml | 4 + .../devicetree/bindings/usb/dwc2.yaml | 4 + MAINTAINERS | 7 + arch/arm/boot/dts/st/stm32mp131.dtsi | 1063 ++++--- arch/arm/boot/dts/st/stm32mp133.dtsi | 51 +- arch/arm/boot/dts/st/stm32mp13xc.dtsi | 19 +- arch/arm/boot/dts/st/stm32mp13xf.dtsi | 19 +- arch/arm/boot/dts/st/stm32mp151.dtsi | 2756 +++++++++-------- arch/arm/boot/dts/st/stm32mp153.dtsi | 52 +- arch/arm/boot/dts/st/stm32mp15xc.dtsi | 19 +- arch/arm/mach-stm32/Kconfig | 1 + arch/arm64/Kconfig.platforms | 1 + arch/arm64/boot/dts/st/stm32mp251.dtsi | 7 +- drivers/bus/Kconfig | 10 + drivers/bus/Makefile | 1 + drivers/bus/stm32_etzpc.c | 141 + drivers/bus/stm32_firewall.c | 294 ++ drivers/bus/stm32_firewall.h | 83 + drivers/bus/stm32_rifsc.c | 252 ++ drivers/of/property.c | 2 + include/linux/bus/stm32_firewall_device.h | 141 + 48 files changed, 3370 insertions(+), 1938 deletions(-) create mode 100644 Documentation/devicetree/bindings/access-controllers/access-controllers.yaml create mode 100644 Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml create mode 100644 Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml create mode 100644 drivers/bus/stm32_etzpc.c create mode 100644 drivers/bus/stm32_firewall.c create mode 100644 drivers/bus/stm32_firewall.h create mode 100644 drivers/bus/stm32_rifsc.c create mode 100644 include/linux/bus/stm32_firewall_device.h -- 2.35.3

5 19