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

[PATCH v2] ASoC: Intel: boards: Add CML_RT1015 m/c driver
by Keith Tzneg 19 Oct '20

19 Oct '20

From: Keith Tzeng <keith.tzeng(a)quanta.corp-partner.google.com> Machine driver to enable RT5682 on SSP0, DMIC, HDMI and RT1015 AMP on SSP1: Enabled 4 CH TDM playback with 24 bit data. Signed-off-by: Keith Tzeng <keith.tzeng(a)quanta.corp-partner.google.com> --- sound/soc/intel/boards/Kconfig | 17 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/cml_rt1015_rt5682.c | 570 ++++++++++++++++++++++ sound/soc/intel/common/soc-acpi-intel-cnl-match.c | 7 + 4 files changed, 596 insertions(+) create mode 100644 sound/soc/intel/boards/cml_rt1015_rt5682.c diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index c10c378..9331d0a 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -496,6 +496,23 @@ config SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH Say Y if you have such a device. If unsure select "N". +config SND_SOC_INTEL_SOF_RT5682_MACH + tristate "SOF with rt5682 codec in I2S Mode" + depends on I2C && ACPI && GPIOLIB + depends on ((SND_HDA_CODEC_HDMI && SND_SOC_SOF_HDA_AUDIO_CODEC) &&\ + (MFD_INTEL_LPSS || COMPILE_TEST)) ||\ + (SND_SOC_SOF_BAYTRAIL && (X86_INTEL_LPSS || COMPILE_TEST)) + select SND_SOC_MAX98373_I2C + select SND_SOC_RT1015 + select SND_SOC_RT5682_I2C + select SND_SOC_DMIC + select SND_SOC_HDAC_HDMI + help + This adds support for ASoC machine driver for SOF platforms + with rt5682 codec. + Say Y if you have such a device. + If unsure select "N". + endif ## SND_SOC_SOF_COMETLAKE && SND_SOC_SOF_HDA_LINK if SND_SOC_SOF_JASPERLAKE diff --git a/sound/soc/intel/boards/Makefile b/sound/soc/intel/boards/Makefile index a58e4d2..73131cc 100644 --- a/sound/soc/intel/boards/Makefile +++ b/sound/soc/intel/boards/Makefile @@ -20,6 +20,7 @@ snd-soc-sst-byt-cht-es8316-objs := bytcht_es8316.o snd-soc-sst-byt-cht-nocodec-objs := bytcht_nocodec.o snd-soc-sof_rt5682-objs := sof_rt5682.o hda_dsp_common.o sof_maxim_common.o snd-soc-cml_rt1011_rt5682-objs := cml_rt1011_rt5682.o hda_dsp_common.o +snd-soc-cml_rt1015_rt5682-objs := cml_rt1015_rt5682.o snd-soc-kbl_da7219_max98357a-objs := kbl_da7219_max98357a.o snd-soc-kbl_da7219_max98927-objs := kbl_da7219_max98927.o snd-soc-kbl_rt5663_max98927-objs := kbl_rt5663_max98927.o @@ -60,6 +61,7 @@ obj-$(CONFIG_SND_SOC_INTEL_BYT_CHT_DA7213_MACH) += snd-soc-sst-byt-cht-da7213.o obj-$(CONFIG_SND_SOC_INTEL_BYT_CHT_ES8316_MACH) += snd-soc-sst-byt-cht-es8316.o obj-$(CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH) += snd-soc-sst-byt-cht-nocodec.o obj-$(CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH) += snd-soc-cml_rt1011_rt5682.o +obj-$(CONFIG_SND_SOC_INTEL_SOF_CML_RT1015_RT5682_MACH) += cml_rt1015_rt5682.o obj-$(CONFIG_SND_SOC_INTEL_KBL_DA7219_MAX98357A_MACH) += snd-soc-kbl_da7219_max98357a.o obj-$(CONFIG_SND_SOC_INTEL_KBL_DA7219_MAX98927_MACH) += snd-soc-kbl_da7219_max98927.o obj-$(CONFIG_SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH) += snd-soc-kbl_rt5663_max98927.o diff --git a/sound/soc/intel/boards/cml_rt1015_rt5682.c b/sound/soc/intel/boards/cml_rt1015_rt5682.c new file mode 100644 index 0000000..bf18830 --- /dev/null +++ b/sound/soc/intel/boards/cml_rt1015_rt5682.c @@ -0,0 +1,570 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright(c) 2019 Intel Corporation. + +/* + * Intel Cometlake I2S Machine driver for RT1015 + RT5682 codec + */ + +#include <linux/input.h> +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/clk.h> +#include <linux/dmi.h> +#include <linux/slab.h> +#include <asm/cpu_device_id.h> +#include <linux/acpi.h> +#include <sound/core.h> +#include <sound/jack.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/soc.h> +#include <sound/rt5682.h> +#include <sound/soc-acpi.h> +#include "../../codecs/rt1015.h" +#include "../../codecs/rt5682.h" +#include "../../codecs/hdac_hdmi.h" + +/* The platform clock outputs 24Mhz clock to codec as I2S MCLK */ +#define CML_PLAT_CLK 24000000 +#define CML_RT1015_CODEC_DAI "rt1015-aif" +#define CML_RT5682_CODEC_DAI "rt5682-aif1" +#define NAME_SIZE 32 + +#define SOF_RT1015_SPEAKER_WL BIT(0) +#define SOF_RT1015_SPEAKER_WR BIT(1) +#define SOF_RT1015_SPEAKER_TL BIT(2) +#define SOF_RT1015_SPEAKER_TR BIT(3) +#define SPK_CH 4 + +/* Default: Woofer speakers */ +static unsigned long sof_rt1015_quirk = SOF_RT1015_SPEAKER_WL | + SOF_RT1015_SPEAKER_WR; + +static int sof_rt1015_quirk_cb(const struct dmi_system_id *id) +{ + sof_rt1015_quirk = (unsigned long)id->driver_data; + return 1; +} + +static const struct dmi_system_id sof_rt1015_quirk_table[] = { + { + .callback = sof_rt1015_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Google"), + DMI_MATCH(DMI_PRODUCT_NAME, "Helios"), + }, + .driver_data = (void *)(SOF_RT1015_SPEAKER_WL | SOF_RT1015_SPEAKER_WR | + SOF_RT1015_SPEAKER_TL | SOF_RT1015_SPEAKER_TR), + }, + { + } +}; + +static struct snd_soc_jack hdmi_jack[3]; + +struct hdmi_pcm { + struct list_head head; + struct snd_soc_dai *codec_dai; + int device; +}; + +struct card_private { + char codec_name[SND_ACPI_I2C_ID_LEN]; + struct snd_soc_jack headset; + struct list_head hdmi_pcm_list; +}; + +static const struct snd_kcontrol_new cml_controls[] = { + SOC_DAPM_PIN_SWITCH("Headphone Jack"), + SOC_DAPM_PIN_SWITCH("Headset Mic"), + SOC_DAPM_PIN_SWITCH("WL Ext Spk"), + SOC_DAPM_PIN_SWITCH("WR Ext Spk"), +}; + +static const struct snd_kcontrol_new cml_rt1015_tt_controls[] = { + SOC_DAPM_PIN_SWITCH("TL Ext Spk"), + SOC_DAPM_PIN_SWITCH("TR Ext Spk"), +}; + +static const struct snd_soc_dapm_widget cml_rt1015_rt5682_widgets[] = { + SND_SOC_DAPM_SPK("WL Ext Spk", NULL), + SND_SOC_DAPM_SPK("WR Ext Spk", NULL), + SND_SOC_DAPM_HP("Headphone Jack", NULL), + SND_SOC_DAPM_MIC("Headset Mic", NULL), + SND_SOC_DAPM_MIC("SoC DMIC", NULL), +}; + +static const struct snd_soc_dapm_widget cml_rt1015_tt_widgets[] = { + SND_SOC_DAPM_SPK("TL Ext Spk", NULL), + SND_SOC_DAPM_SPK("TR Ext Spk", NULL), +}; + +static const struct snd_soc_dapm_route cml_rt1015_rt5682_map[] = { + /*WL/WR speaker*/ + {"WL Ext Spk", NULL, "WL SPO"}, + {"WR Ext Spk", NULL, "WR SPO"}, + + /* HP jack connectors - unknown if we have jack detection */ + { "Headphone Jack", NULL, "HPOL" }, + { "Headphone Jack", NULL, "HPOR" }, + + /* other jacks */ + { "IN1P", NULL, "Headset Mic" }, + + /* DMIC */ + { "DMic", NULL, "SoC DMIC" }, +}; + +static const struct snd_soc_dapm_route cml_rt1015_tt_map[] = { + /*TL/TR speaker*/ + {"TL Ext Spk", NULL, "TL SPO" }, + {"TR Ext Spk", NULL, "TR SPO" }, +}; + +static int cml_rt5682_codec_init(struct snd_soc_pcm_runtime *rtd) +{ + struct card_private *ctx = snd_soc_card_get_drvdata(rtd->card); + struct snd_soc_component *component = rtd->codec_dai->component; + struct snd_soc_jack *jack; + int ret; + + /* need to enable ASRC function for 24MHz mclk rate */ + rt5682_sel_asrc_clk_src(component, RT5682_DA_STEREO1_FILTER | + RT5682_AD_STEREO1_FILTER, + RT5682_CLK_SEL_I2S1_ASRC); + + /* + * Headset buttons map to the google Reference headset. + * These can be configured by userspace. + */ + ret = snd_soc_card_jack_new(rtd->card, "Headset Jack", + SND_JACK_HEADSET | SND_JACK_BTN_0 | + SND_JACK_BTN_1 | SND_JACK_BTN_2 | + SND_JACK_BTN_3, + &ctx->headset, NULL, 0); + if (ret) { + dev_err(rtd->dev, "Headset Jack creation failed: %d\n", ret); + return ret; + } + + jack = &ctx->headset; + + snd_jack_set_key(jack->jack, SND_JACK_BTN_0, KEY_PLAYPAUSE); + snd_jack_set_key(jack->jack, SND_JACK_BTN_1, KEY_VOICECOMMAND); + snd_jack_set_key(jack->jack, SND_JACK_BTN_2, KEY_VOLUMEUP); + snd_jack_set_key(jack->jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN); + ret = snd_soc_component_set_jack(component, jack, NULL); + if (ret) + dev_err(rtd->dev, "Headset Jack call-back failed: %d\n", ret); + + return ret; +}; + +static int cml_rt1015_spk_init(struct snd_soc_pcm_runtime *rtd) +{ + int ret = 0; + struct snd_soc_card *card = rtd->card; + + if (sof_rt1015_quirk & (SOF_RT1015_SPEAKER_TL | + SOF_RT1015_SPEAKER_TR)) { + + ret = snd_soc_add_card_controls(card, cml_rt1015_tt_controls, + ARRAY_SIZE(cml_rt1015_tt_controls)); + if (ret) + return ret; + + ret = snd_soc_dapm_new_controls(&card->dapm, + cml_rt1015_tt_widgets, + ARRAY_SIZE(cml_rt1015_tt_widgets)); + if (ret) + return ret; + + ret = snd_soc_dapm_add_routes(&card->dapm, cml_rt1015_tt_map, + ARRAY_SIZE(cml_rt1015_tt_map)); + + if (ret) + return ret; + } + + return ret; +} + +static int cml_rt5682_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *codec_dai = rtd->codec_dai; + int clk_id, clk_freq, pll_out, ret; + + clk_id = RT5682_PLL1_S_MCLK; + clk_freq = CML_PLAT_CLK; + + pll_out = params_rate(params) * 512; + + ret = snd_soc_dai_set_pll(codec_dai, 0, clk_id, clk_freq, pll_out); + if (ret < 0) + dev_warn(rtd->dev, "snd_soc_dai_set_pll err = %d\n", ret); + + /* Configure sysclk for codec */ + ret = snd_soc_dai_set_sysclk(codec_dai, RT5682_SCLK_S_PLL1, + pll_out, SND_SOC_CLOCK_IN); + if (ret < 0) + dev_warn(rtd->dev, "snd_soc_dai_set_sysclk err = %d\n", ret); + + /* + * slot_width should be equal or large than data length, set them + * be the same + */ + ret = snd_soc_dai_set_tdm_slot(codec_dai, 0x0, 0x0, 2, + params_width(params)); + if (ret < 0) + dev_warn(rtd->dev, "set TDM slot err:%d\n", ret); + return ret; +} + +static int cml_rt1015_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *codec_dai; + struct snd_soc_card *card = rtd->card; + int srate, i, ret = 0; + + srate = params_rate(params); + + for_each_rtd_codec_dai(rtd, i, codec_dai) { + /* Set tdm/i2s1 master bclk ratio */ + ret = snd_soc_dai_set_bclk_ratio(codec_dai, 64); + if (ret < 0) { + dev_err(card->dev, "failed to set bclk ratio\n"); + return ret; + } + /* 64 Fs to drive 24 bit data */ + ret = snd_soc_dai_set_pll(codec_dai, 0, RT1015_PLL_S_BCLK, + 64 * srate, 256 * srate); + if (ret < 0) { + dev_err(card->dev, "codec_dai clock not set\n"); + return ret; + } + + ret = snd_soc_dai_set_sysclk(codec_dai, + RT1015_SCLK_S_PLL, + 256 * srate, SND_SOC_CLOCK_IN); + if (ret < 0) { + dev_err(card->dev, "codec_dai clock not set\n"); + return ret; + } + + } + return 0; +} + +static struct snd_soc_ops cml_rt5682_ops = { + .hw_params = cml_rt5682_hw_params, +}; + +static const struct snd_soc_ops cml_rt1015_ops = { + .hw_params = cml_rt1015_hw_params, +}; + +static int sof_card_late_probe(struct snd_soc_card *card) +{ + struct card_private *ctx = snd_soc_card_get_drvdata(card); + struct snd_soc_component *component = NULL; + char jack_name[NAME_SIZE]; + struct hdmi_pcm *pcm; + int ret, i = 0; + + list_for_each_entry(pcm, &ctx->hdmi_pcm_list, head) { + component = pcm->codec_dai->component; + snprintf(jack_name, sizeof(jack_name), + "HDMI/DP, pcm=%d Jack", pcm->device); + ret = snd_soc_card_jack_new(card, jack_name, + SND_JACK_AVOUT, &hdmi_jack[i], + NULL, 0); + if (ret) + return ret; + + ret = hdac_hdmi_jack_init(pcm->codec_dai, pcm->device, + &hdmi_jack[i]); + if (ret < 0) + return ret; + + i++; + } + if (!component) + return -EINVAL; + + return hdac_hdmi_jack_port_init(component, &card->dapm); +} + +static int hdmi_init(struct snd_soc_pcm_runtime *rtd) +{ + struct card_private *ctx = snd_soc_card_get_drvdata(rtd->card); + struct snd_soc_dai *dai = rtd->codec_dai; + struct hdmi_pcm *pcm; + + pcm = devm_kzalloc(rtd->card->dev, sizeof(*pcm), GFP_KERNEL); + if (!pcm) + return -ENOMEM; + + pcm->device = dai->id; + pcm->codec_dai = dai; + + list_add_tail(&pcm->head, &ctx->hdmi_pcm_list); + + return 0; +} + +/* Cometlake digital audio interface glue - connects codec <--> CPU */ + +SND_SOC_DAILINK_DEF(ssp0_pin, + DAILINK_COMP_ARRAY(COMP_CPU("SSP0 Pin"))); +SND_SOC_DAILINK_DEF(ssp0_codec, + DAILINK_COMP_ARRAY(COMP_CODEC("i2c-10EC5682:00", + CML_RT5682_CODEC_DAI))); + +SND_SOC_DAILINK_DEF(ssp1_pin, + DAILINK_COMP_ARRAY(COMP_CPU("SSP1 Pin"))); +SND_SOC_DAILINK_DEF(ssp1_codec, + DAILINK_COMP_ARRAY( + /* WL */ COMP_CODEC("i2c-10EC1015:00", CML_RT1015_CODEC_DAI), + /* WR */ COMP_CODEC("i2c-10EC1015:01", CML_RT1015_CODEC_DAI))); + +SND_SOC_DAILINK_DEF(dmic_pin, + DAILINK_COMP_ARRAY(COMP_CPU("DMIC01 Pin"))); + +SND_SOC_DAILINK_DEF(dmic16k_pin, + DAILINK_COMP_ARRAY(COMP_CPU("DMIC16k Pin"))); + +SND_SOC_DAILINK_DEF(dmic_codec, + DAILINK_COMP_ARRAY(COMP_CODEC("dmic-codec", "dmic-hifi"))); + +SND_SOC_DAILINK_DEF(idisp1_pin, + DAILINK_COMP_ARRAY(COMP_CPU("iDisp1 Pin"))); +SND_SOC_DAILINK_DEF(idisp1_codec, + DAILINK_COMP_ARRAY(COMP_CODEC("ehdaudio0D2", "intel-hdmi-hifi1"))); + +SND_SOC_DAILINK_DEF(idisp2_pin, + DAILINK_COMP_ARRAY(COMP_CPU("iDisp2 Pin"))); +SND_SOC_DAILINK_DEF(idisp2_codec, + DAILINK_COMP_ARRAY(COMP_CODEC("ehdaudio0D2", "intel-hdmi-hifi2"))); + +SND_SOC_DAILINK_DEF(idisp3_pin, + DAILINK_COMP_ARRAY(COMP_CPU("iDisp3 Pin"))); +SND_SOC_DAILINK_DEF(idisp3_codec, + DAILINK_COMP_ARRAY(COMP_CODEC("ehdaudio0D2", "intel-hdmi-hifi3"))); + +SND_SOC_DAILINK_DEF(platform, + DAILINK_COMP_ARRAY(COMP_PLATFORM("0000:00:1f.3"))); + +static struct snd_soc_dai_link cml_rt1015_rt5682_dailink[] = { + /* Back End DAI links */ + { + /* SSP0 - Codec */ + .name = "SSP0-Codec", + .id = 0, + .init = cml_rt5682_codec_init, + .ignore_pmdown_time = 1, + .ops = &cml_rt5682_ops, + .dpcm_playback = 1, + .dpcm_capture = 1, + .no_pcm = 1, + SND_SOC_DAILINK_REG(ssp0_pin, ssp0_codec, platform), + }, + { + .name = "dmic01", + .id = 1, + .ignore_suspend = 1, + .dpcm_capture = 1, + .no_pcm = 1, + SND_SOC_DAILINK_REG(dmic_pin, dmic_codec, platform), + }, + { + .name = "dmic16k", + .id = 2, + .ignore_suspend = 1, + .dpcm_capture = 1, + .no_pcm = 1, + SND_SOC_DAILINK_REG(dmic16k_pin, dmic_codec, platform), + }, + { + .name = "iDisp1", + .id = 3, + .init = hdmi_init, + .dpcm_playback = 1, + .no_pcm = 1, + SND_SOC_DAILINK_REG(idisp1_pin, idisp1_codec, platform), + }, + { + .name = "iDisp2", + .id = 4, + .init = hdmi_init, + .dpcm_playback = 1, + .no_pcm = 1, + SND_SOC_DAILINK_REG(idisp2_pin, idisp2_codec, platform), + }, + { + .name = "iDisp3", + .id = 5, + .init = hdmi_init, + .dpcm_playback = 1, + .no_pcm = 1, + SND_SOC_DAILINK_REG(idisp3_pin, idisp3_codec, platform), + }, + { + /* + * SSP1 - Codec : added to end of list ensuring + * reuse of common topologies for other end points + * and changing only SSP1's codec + */ + .name = "SSP1-Codec", + .id = 6, + .dpcm_playback = 1, + .no_pcm = 1, + .init = cml_rt1015_spk_init, + .ops = &cml_rt1015_ops, + SND_SOC_DAILINK_REG(ssp1_pin, ssp1_codec, platform), + }, +}; + +static struct snd_soc_codec_conf rt1015_conf[] = { + { + .dev_name = "i2c-10EC1015:00", + .name_prefix = "WL", + }, + { + .dev_name = "i2c-10EC1015:01", + .name_prefix = "WR", + }, +}; + +/* Cometlake audio machine driver for RT1015 and RT5682 */ +static struct snd_soc_card snd_soc_card_cml = { + .name = "cml_rt1015_rt5682", + .dai_link = cml_rt1015_rt5682_dailink, + .num_links = ARRAY_SIZE(cml_rt1015_rt5682_dailink), + .codec_conf = rt1015_conf, + .num_configs = ARRAY_SIZE(rt1015_conf), + .dapm_widgets = cml_rt1015_rt5682_widgets, + .num_dapm_widgets = ARRAY_SIZE(cml_rt1015_rt5682_widgets), + .dapm_routes = cml_rt1015_rt5682_map, + .num_dapm_routes = ARRAY_SIZE(cml_rt1015_rt5682_map), + .controls = cml_controls, + .num_controls = ARRAY_SIZE(cml_controls), + .fully_routed = true, + .late_probe = sof_card_late_probe, +}; + +static int snd_cml_rt1015_probe(struct platform_device *pdev) +{ + struct snd_soc_dai_link_component *rt1015_dais_components; + struct snd_soc_codec_conf *rt1015_dais_confs; + struct card_private *ctx; + struct snd_soc_acpi_mach *mach; + const char *platform_name; + int ret, i; + + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_ATOMIC); + if (!ctx) + return -ENOMEM; + + INIT_LIST_HEAD(&ctx->hdmi_pcm_list); + mach = (&pdev->dev)->platform_data; + snd_soc_card_cml.dev = &pdev->dev; + platform_name = mach->mach_params.platform; + + dmi_check_system(sof_rt1015_quirk_table); + + dev_info(&pdev->dev, "sof_rt1015_quirk = %lx\n", sof_rt1015_quirk); + + if (sof_rt1015_quirk & (SOF_RT1015_SPEAKER_TL | + SOF_RT1015_SPEAKER_TR)) { + rt1015_dais_confs = devm_kzalloc(&pdev->dev, + sizeof(struct snd_soc_codec_conf) * + SPK_CH, GFP_KERNEL); + + if (!rt1015_dais_confs) + return -ENOMEM; + + rt1015_dais_components = devm_kzalloc(&pdev->dev, + sizeof(struct snd_soc_dai_link_component) * + SPK_CH, GFP_KERNEL); + + if (!rt1015_dais_components) + return -ENOMEM; + + for (i = 0; i < SPK_CH; i++) { + rt1015_dais_confs[i].dev_name = devm_kasprintf(&pdev->dev, + GFP_KERNEL, + "i2c-10EC1015:0%d", + i); + + if (!rt1015_dais_confs[i].dev_name) + return -ENOMEM; + + switch (i) { + case 0: + rt1015_dais_confs[i].name_prefix = "WL"; + break; + case 1: + rt1015_dais_confs[i].name_prefix = "WR"; + break; + case 2: + rt1015_dais_confs[i].name_prefix = "TL"; + break; + case 3: + rt1015_dais_confs[i].name_prefix = "TR"; + break; + default: + return -EINVAL; + } + rt1015_dais_components[i].name = devm_kasprintf(&pdev->dev, + GFP_KERNEL, + "i2c-10EC1015:0%d", + i); + if (!rt1015_dais_components[i].name) + return -ENOMEM; + + rt1015_dais_components[i].dai_name = CML_RT1015_CODEC_DAI; + } + + snd_soc_card_cml.codec_conf = rt1015_dais_confs; + snd_soc_card_cml.num_configs = SPK_CH; + + for (i = 0; i < ARRAY_SIZE(cml_rt1015_rt5682_dailink); i++) { + if (!strcmp(cml_rt1015_rt5682_dailink[i].codecs->dai_name, + CML_RT1015_CODEC_DAI)) { + cml_rt1015_rt5682_dailink[i].codecs = rt1015_dais_components; + cml_rt1015_rt5682_dailink[i].num_codecs = SPK_CH; + } + } + } + + /* set platform name for each dailink */ + ret = snd_soc_fixup_dai_links_platform_name(&snd_soc_card_cml, + platform_name); + if (ret) + return ret; + snd_soc_card_set_drvdata(&snd_soc_card_cml, ctx); + + return devm_snd_soc_register_card(&pdev->dev, &snd_soc_card_cml); +} + +static struct platform_driver snd_cml_rt1015_rt5682_driver = { + .probe = snd_cml_rt1015_probe, + .driver = { + .name = "cml_rt1015_rt5682", + .pm = &snd_soc_pm_ops, + }, +}; +module_platform_driver(snd_cml_rt1015_rt5682_driver); + +/* Module information */ +MODULE_DESCRIPTION("Cometlake Audio Machine driver - RT1015 and RT5682 in I2S mode"); +MODULE_AUTHOR("Naveen Manohar <naveen.m(a)intel.com>"); +MODULE_AUTHOR("Sathya Prakash M R <sathya.prakash.m.r(a)intel.com>"); +MODULE_AUTHOR("Shuming Fan <shumingf(a)realtek.com>"); +MODULE_AUTHOR("Mac Chiang <mac.chiang(a)intel.com>"); +MODULE_LICENSE("GPL v2"); +MODULE_ALIAS("platform:cml_rt1015_rt5682"); diff --git a/sound/soc/intel/common/soc-acpi-intel-cnl-match.c b/sound/soc/intel/common/soc-acpi-intel-cnl-match.c index b80f032a..4f99da8 100644 --- a/sound/soc/intel/common/soc-acpi-intel-cnl-match.c +++ b/sound/soc/intel/common/soc-acpi-intel-cnl-match.c @@ -23,6 +23,13 @@ struct snd_soc_acpi_mach snd_soc_acpi_intel_cnl_machines[] = { .sof_fw_filename = "sof-cnl.ri", .sof_tplg_filename = "sof-cnl-rt274.tplg", }, + { + .id = "10EC1015", + .drv_name = "cml_rt1015_rt5682", + .quirk_data = &cml_codecs, + .sof_fw_filename = "sof-cnl.ri", + .sof_tplg_filename = "sof-cml-rt1015-rt5682.tplg", + }, {}, }; EXPORT_SYMBOL_GPL(snd_soc_acpi_intel_cnl_machines); -- 2.7.4

2 1

No sound after upgrade from 1.2.3 to 1.2.4 (Xiaomi Redmibook 16 II Ryzen Edition)
by GitHub issues - opened 19 Oct '20

19 Oct '20

alsa-project/alsa-ucm-conf issue #55 was opened from deponian: Hello. Yesterday I have upgraded Arch Linux on my laptop with `pacman -Syu` and after reboot I've had no sound from built-in speakers. I had downgraded all upgraded packages and started upgrading one-by-one with reboot after every step. I have found out that upgrading `alsa-ucm-conf` package from `1.2.3-2` to `1.2.4-1` is causing the issue. If I understand correctly my laptop has something called `Family 17h (Models 10h-1fh) HD Audio Controller` which is using for output and `Raven/Raven2/FireFlight/Renoir Audio Processor Stereo` which is using for input. After upgrading to `1.2.4` I had had only broken output, the input (microphone) was working correctly. I have attached two outputs of `alsa-info.sh` to this message: one before and other one after upgrade. [alsa-info-1.2.3.txt](https://github.com/alsa-project/alsa-ucm-conf/files/54… [alsa-info-1.2.4.txt](https://github.com/alsa-project/alsa-ucm-conf/files/54… I hope it will help. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/55 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH] ASoC: mediatek: mt8183-da7219: fix DAPM paths for rt1015
by Tzung-Bi Shih 19 Oct '20

19 Oct '20

RT1015's output widget name is "SPO" instead of "Speaker". Fixes it to use the correct names. Signed-off-by: Tzung-Bi Shih <tzungbi(a)google.com> --- .../mediatek/mt8183/mt8183-da7219-max98357.c | 31 +++++++++++++++---- 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c b/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c index c2c1eb16fcc0..26e7d9a7198f 100644 --- a/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c +++ b/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c @@ -630,15 +630,34 @@ static struct snd_soc_codec_conf mt8183_da7219_rt1015_codec_conf[] = { }, }; +static const struct snd_kcontrol_new mt8183_da7219_rt1015_snd_controls[] = { + SOC_DAPM_PIN_SWITCH("Left Spk"), + SOC_DAPM_PIN_SWITCH("Right Spk"), +}; + +static const +struct snd_soc_dapm_widget mt8183_da7219_rt1015_dapm_widgets[] = { + SND_SOC_DAPM_SPK("Left Spk", NULL), + SND_SOC_DAPM_SPK("Right Spk", NULL), + SND_SOC_DAPM_PINCTRL("TDM_OUT_PINCTRL", + "aud_tdm_out_on", "aud_tdm_out_off"), +}; + +static const struct snd_soc_dapm_route mt8183_da7219_rt1015_dapm_routes[] = { + {"Left Spk", NULL, "Left SPO"}, + {"Right Spk", NULL, "Right SPO"}, + {"I2S Playback", NULL, "TDM_OUT_PINCTRL"}, +}; + static struct snd_soc_card mt8183_da7219_rt1015_card = { .name = "mt8183_da7219_rt1015", .owner = THIS_MODULE, - .controls = mt8183_da7219_max98357_snd_controls, - .num_controls = ARRAY_SIZE(mt8183_da7219_max98357_snd_controls), - .dapm_widgets = mt8183_da7219_max98357_dapm_widgets, - .num_dapm_widgets = ARRAY_SIZE(mt8183_da7219_max98357_dapm_widgets), - .dapm_routes = mt8183_da7219_max98357_dapm_routes, - .num_dapm_routes = ARRAY_SIZE(mt8183_da7219_max98357_dapm_routes), + .controls = mt8183_da7219_rt1015_snd_controls, + .num_controls = ARRAY_SIZE(mt8183_da7219_rt1015_snd_controls), + .dapm_widgets = mt8183_da7219_rt1015_dapm_widgets, + .num_dapm_widgets = ARRAY_SIZE(mt8183_da7219_rt1015_dapm_widgets), + .dapm_routes = mt8183_da7219_rt1015_dapm_routes, + .num_dapm_routes = ARRAY_SIZE(mt8183_da7219_rt1015_dapm_routes), .dai_link = mt8183_da7219_dai_links, .num_links = ARRAY_SIZE(mt8183_da7219_dai_links), .aux_dev = &mt8183_da7219_max98357_headset_dev, -- 2.29.0.rc1.297.gfa9743e501-goog

2 1

[PATCH] ASoC: amd: move the call to devm_kzalloc below platform_get_resource()
by Defang Bo 19 Oct '20

19 Oct '20

Just as the commit <4cb79ef9c6c4>("ASoC: amd: Fix potential NULL pointer dereference"),it makes no sense to allocate any resources if res = platform_get_resource(pdev, IORESOURCE_MEM, 0); fails,so move the call to devm_kzalloc() below the mentioned code. Signed-off-by: Defang Bo <bodefang(a)126.com> --- sound/soc/amd/raven/acp3x-i2s.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/sound/soc/amd/raven/acp3x-i2s.c b/sound/soc/amd/raven/acp3x-i2s.c index a532e01..c9c69eb 100644 --- a/sound/soc/amd/raven/acp3x-i2s.c +++ b/sound/soc/amd/raven/acp3x-i2s.c @@ -302,16 +302,14 @@ static int acp3x_dai_probe(struct platform_device *pdev) struct i2s_dev_data *adata; int ret; - adata = devm_kzalloc(&pdev->dev, sizeof(struct i2s_dev_data), - GFP_KERNEL); - if (!adata) - return -ENOMEM; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { dev_err(&pdev->dev, "IORESOURCE_MEM FAILED\n"); return -ENOMEM; } + adata = devm_kzalloc(&pdev->dev, sizeof(struct i2s_dev_data), GFP_KERNEL); + if (!adata) + return -ENOMEM; adata->acp3x_base = devm_ioremap(&pdev->dev, res->start, resource_size(res)); if (!adata->acp3x_base) -- 1.9.1

2 1

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Pavel Machek 19 Oct '20

19 Oct '20

On Wed 2020-10-14 10:34:21, Udo van den Heuvel wrote: > On 14-10-2020 10:27, Pavel Machek wrote: > >> One should have thought about stuff beforehand. > > > > We did. And decided this is best solution. > > Then the thought process went awry. > > >> The non-selectability is not my fault. > > > > It also does not affect you in any way. > > It does. > /boot fills up even sooner thanks to this unused code. > Compiles last longer because of this unused code. Have you measured how much slower and how much bigger it is? Do you understand that you propose to make source code bigger and slower to compile for everyone else? You are filling my inbox. > > Feel free to go to the mic LED discussion to see why we did it like > > this. Then you can come up with better solution for problem at hand. > > I did not think of forcing code onto somebody. Someone else did. > This is effectively the effect of the LEDs thing. Without understanding what was decided and why, this discussion is not useful. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

3 2

[PATCH v6 00/14] Add Allwinner H3/H5/H6/A64 HDMI audio
by Clément Péron 19 Oct '20

19 Oct '20

Hi, To avoid using set-tdm property of the simple-soundcard we will introduce a specific soundcard for Allwinner HDMI later. So I have dropped the simple-soundcard, the title of the serie is no more relevent... Regards, Clement Change since v5: - Drop HDMI simple soundcard - Collect Chen-Yu Tsai tags - Configure channels from 9 to 15. - Remove DMA RX for H3/H5 - Fix Documentation for H3/H5 Change since v4: - add more comment on get_wss() and set_channel_cfg() patch - merge soundcard and DAI HDMI patches Change since v3: - add Samuel Holland patch to reconfigure FIFO_TX_REG when suspend is enabled - readd inversion to H6 LRCK sun50i_h6_i2s_set_soc_fmt() - Fix get_wss() for sun4i - Add a commit to fix checkpatch warning Change since v2: - rebase on next-20200918 - drop revert LRCK polarity patch - readd simple-audio-card,frame-inversion in dts - Add patch for changing set_chan_cfg params Change since v1: - rebase on next-20200828 - add revert LRCK polarity - remove all simple-audio-card,frame-inversion in dts - add Ondrej patches for Orange Pi board - Add arm64 defconfig patch *** BLURB HERE *** Clément Péron (6): ASoC: sun4i-i2s: Change set_chan_cfg() params ASoC: sun4i-i2s: Change get_sr() and get_wss() to be more explicit ASoC: sun4i-i2s: Fix sun8i volatile regs ASoC: sun4i-i2s: fix coding-style for callback definition arm64: defconfig: Enable Allwinner i2s driver dt-bindings: sound: sun4i-i2s: Document H3 with missing RX channel possibility Jernej Skrabec (3): ASoC: sun4i-i2s: Add support for H6 I2S dt-bindings: ASoC: sun4i-i2s: Add H6 compatible arm64: dts: allwinner: h6: Add I2S1 node Marcus Cooper (4): ASoC: sun4i-i2s: Set sign extend sample ASoc: sun4i-i2s: Add 20 and 24 bit support arm64: dts: allwinner: a64: Add I2S2 node arm: dts: sunxi: h3/h5: Add I2S2 node Samuel Holland (1): ASoC: sun4i-i2s: Fix setting of FIFO modes .../sound/allwinner,sun4i-a10-i2s.yaml | 6 +- arch/arm/boot/dts/sunxi-h3-h5.dtsi | 13 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 14 + arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 13 + arch/arm64/configs/defconfig | 1 + sound/soc/sunxi/sun4i-i2s.c | 376 +++++++++++++++--- 6 files changed, 368 insertions(+), 55 deletions(-) -- 2.25.1

4 25

1.2.4: symlinks in /lib/firmware/turtlebeach pointing to nowhere
by GitHub issues - opened 18 Oct '20

18 Oct '20

alsa-project/alsa-firmware issue #2 was opened from kloczek: ``` drwxr-xr-x 2 root root 0 Oct 18 21:38 /lib/firmware/turtlebeach lrwxrwxrwx 1 root root 23 Oct 18 21:38 /lib/firmware/turtlebeach/msndinit.bin -> /etc/sound/msndinit.bin lrwxrwxrwx 1 root root 23 Oct 18 21:38 /lib/firmware/turtlebeach/msndperm.bin -> /etc/sound/msndperm.bin lrwxrwxrwx 1 root root 23 Oct 18 21:38 /lib/firmware/turtlebeach/pndsperm.bin -> /etc/sound/pndsperm.bin lrwxrwxrwx 1 root root 23 Oct 18 21:38 /lib/firmware/turtlebeach/pndspini.bin -> /etc/sound/pndspini.bin ``` Looks like thoose symlinks are pointing to nowhere. Issue URL : https://github.com/alsa-project/alsa-firmware/issues/2 Repository URL: https://github.com/alsa-project/alsa-firmware

1 0

[PATCH AUTOSEL 5.4 73/80] ALSA: hda/ca0132 - Add new quirk ID for SoundBlaster AE-7.
by Sasha Levin 18 Oct '20

18 Oct '20

From: Connor McAdams <conmanx360(a)gmail.com> [ Upstream commit 620f08eea6d6961b789af3fa3ea86725c8c93ece ] Add a new PCI subsystem ID for the SoundBlaster AE-7 card. Signed-off-by: Connor McAdams <conmanx360(a)gmail.com> Link: https://lore.kernel.org/r/20200825201040.30339-11-conmanx360@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_ca0132.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index 98a11c38e7a8e..459aff6c10bc5 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -1065,6 +1065,7 @@ enum { QUIRK_R3DI, QUIRK_R3D, QUIRK_AE5, + QUIRK_AE7, }; #ifdef CONFIG_PCI @@ -1184,6 +1185,7 @@ static const struct snd_pci_quirk ca0132_quirks[] = { SND_PCI_QUIRK(0x1102, 0x0013, "Recon3D", QUIRK_R3D), SND_PCI_QUIRK(0x1102, 0x0018, "Recon3D", QUIRK_R3D), SND_PCI_QUIRK(0x1102, 0x0051, "Sound Blaster AE-5", QUIRK_AE5), + SND_PCI_QUIRK(0x1102, 0x0081, "Sound Blaster AE-7", QUIRK_AE7), {} }; -- 2.25.1

1 0

[PATCH AUTOSEL 5.4 72/80] ALSA: hda/ca0132 - Add AE-7 microphone selection commands.
by Sasha Levin 18 Oct '20

18 Oct '20

From: Connor McAdams <conmanx360(a)gmail.com> [ Upstream commit ed93f9750c6c2ed371347d0aac3dcd31cb9cf256 ] Add AE-7 quirk data for setting of microphone. The AE-7 has no front panel connector, so only rear-mic/line-in have new commands. Signed-off-by: Connor McAdams <conmanx360(a)gmail.com> Link: https://lore.kernel.org/r/20200825201040.30339-19-conmanx360@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_ca0132.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index 6aa39339db0ab..98a11c38e7a8e 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -4674,6 +4674,15 @@ static int ca0132_alt_select_in(struct hda_codec *codec) ca0113_mmio_command_set(codec, 0x30, 0x28, 0x00); tmp = FLOAT_THREE; break; + case QUIRK_AE7: + ca0113_mmio_command_set(codec, 0x30, 0x28, 0x00); + tmp = FLOAT_THREE; + chipio_set_conn_rate(codec, MEM_CONNID_MICIN2, + SR_96_000); + chipio_set_conn_rate(codec, MEM_CONNID_MICOUT2, + SR_96_000); + dspio_set_uint_param(codec, 0x80, 0x01, FLOAT_ZERO); + break; default: tmp = FLOAT_ONE; break; @@ -4719,6 +4728,14 @@ static int ca0132_alt_select_in(struct hda_codec *codec) case QUIRK_AE5: ca0113_mmio_command_set(codec, 0x30, 0x28, 0x00); break; + case QUIRK_AE7: + ca0113_mmio_command_set(codec, 0x30, 0x28, 0x3f); + chipio_set_conn_rate(codec, MEM_CONNID_MICIN2, + SR_96_000); + chipio_set_conn_rate(codec, MEM_CONNID_MICOUT2, + SR_96_000); + dspio_set_uint_param(codec, 0x80, 0x01, FLOAT_ZERO); + break; default: break; } @@ -4728,7 +4745,10 @@ static int ca0132_alt_select_in(struct hda_codec *codec) if (ca0132_quirk(spec) == QUIRK_R3DI) chipio_set_conn_rate(codec, 0x0F, SR_96_000); - tmp = FLOAT_ZERO; + if (ca0132_quirk(spec) == QUIRK_AE7) + tmp = FLOAT_THREE; + else + tmp = FLOAT_ZERO; dspio_set_uint_param(codec, 0x80, 0x00, tmp); switch (ca0132_quirk(spec)) { -- 2.25.1

1 0

[PATCH AUTOSEL 5.8 093/101] ASoC: Intel: sof_rt5682: override quirk data for tgl_max98373_rt5682
by Sasha Levin 18 Oct '20

18 Oct '20

From: Sathyanarayana Nujella <sathyanarayana.nujella(a)intel.com> [ Upstream commit 3e1734b64ce786c54dc98adcfe67941e6011d735 ] A Chrome System based on tgl_max98373_rt5682 has different SSP interface configurations. Using DMI data of this variant DUT, override quirk data. Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella(a)intel.com> Signed-off-by: Mac Chiang <mac.chiang(a)intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20200821195603.215535-13-pierre-louis.bossart@lin… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/intel/boards/sof_rt5682.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c index 13a48b0c35aef..11233c3aeadfb 100644 --- a/sound/soc/intel/boards/sof_rt5682.c +++ b/sound/soc/intel/boards/sof_rt5682.c @@ -118,6 +118,19 @@ static const struct dmi_system_id sof_rt5682_quirk_table[] = { .driver_data = (void *)(SOF_RT5682_MCLK_EN | SOF_RT5682_SSP_CODEC(0)), }, + { + .callback = sof_rt5682_quirk_cb, + .matches = { + DMI_MATCH(DMI_PRODUCT_FAMILY, "Google_Volteer"), + DMI_MATCH(DMI_PRODUCT_NAME, "Terrador"), + }, + .driver_data = (void *)(SOF_RT5682_MCLK_EN | + SOF_RT5682_SSP_CODEC(0) | + SOF_SPEAKER_AMP_PRESENT | + SOF_MAX98373_SPEAKER_AMP_PRESENT | + SOF_RT5682_SSP_AMP(2) | + SOF_RT5682_NUM_HDMIDEV(4)), + }, {} }; -- 2.25.1

1 0

[PATCH AUTOSEL 5.8 092/101] ASoC: SOF: Add topology filename override based on dmi data match
by Sasha Levin 18 Oct '20

18 Oct '20

From: Sathyanarayana Nujella <sathyanarayana.nujella(a)intel.com> [ Upstream commit 5253a73d567dcd75e62834ff5f502ea9470e5722 ] Add topology filename override based on system DMI data matching, typically to account for a different hardware layout. In ACPI based systems, the tplg_filename is pre-defined in an ACPI machine table. When a DMI quirk is detected, the sof_pdata->tplg_filename is not set with the hard-coded ACPI value, and instead is set with the DMI-specific filename. Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella(a)intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20200821195603.215535-14-pierre-louis.bossart@lin… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda.c | 8 +++++++- sound/soc/sof/sof-pci-dev.c | 24 ++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 1 deletion(-) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index 63ca920c8e6e0..7152e6d1cf673 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -1179,7 +1179,13 @@ void hda_machine_select(struct snd_sof_dev *sdev) mach = snd_soc_acpi_find_machine(desc->machines); if (mach) { - sof_pdata->tplg_filename = mach->sof_tplg_filename; + /* + * If tplg file name is overridden, use it instead of + * the one set in mach table + */ + if (!sof_pdata->tplg_filename) + sof_pdata->tplg_filename = mach->sof_tplg_filename; + sof_pdata->machine = mach; if (mach->link_mask) { diff --git a/sound/soc/sof/sof-pci-dev.c b/sound/soc/sof/sof-pci-dev.c index aa3532ba14349..f3a8140773db5 100644 --- a/sound/soc/sof/sof-pci-dev.c +++ b/sound/soc/sof/sof-pci-dev.c @@ -35,8 +35,28 @@ static int sof_pci_debug; module_param_named(sof_pci_debug, sof_pci_debug, int, 0444); MODULE_PARM_DESC(sof_pci_debug, "SOF PCI debug options (0x0 all off)"); +static const char *sof_override_tplg_name; + #define SOF_PCI_DISABLE_PM_RUNTIME BIT(0) +static int sof_tplg_cb(const struct dmi_system_id *id) +{ + sof_override_tplg_name = id->driver_data; + return 1; +} + +static const struct dmi_system_id sof_tplg_table[] = { + { + .callback = sof_tplg_cb, + .matches = { + DMI_MATCH(DMI_PRODUCT_FAMILY, "Google_Volteer"), + DMI_MATCH(DMI_PRODUCT_NAME, "Terrador"), + }, + .driver_data = "sof-tgl-rt5682-ssp0-max98373-ssp2.tplg", + }, + {} +}; + static const struct dmi_system_id community_key_platforms[] = { { .ident = "Up Squared", @@ -347,6 +367,10 @@ static int sof_pci_probe(struct pci_dev *pci, sof_pdata->tplg_filename_prefix = sof_pdata->desc->default_tplg_path; + dmi_check_system(sof_tplg_table); + if (sof_override_tplg_name) + sof_pdata->tplg_filename = sof_override_tplg_name; + #if IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE) /* set callback to enable runtime_pm */ sof_pdata->sof_probe_complete = sof_pci_probe_complete; -- 2.25.1

1 0

[PATCH AUTOSEL 5.8 091/101] ALSA: hda/ca0132 - Add new quirk ID for SoundBlaster AE-7.
by Sasha Levin 18 Oct '20

18 Oct '20

From: Connor McAdams <conmanx360(a)gmail.com> [ Upstream commit 620f08eea6d6961b789af3fa3ea86725c8c93ece ] Add a new PCI subsystem ID for the SoundBlaster AE-7 card. Signed-off-by: Connor McAdams <conmanx360(a)gmail.com> Link: https://lore.kernel.org/r/20200825201040.30339-11-conmanx360@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_ca0132.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index 62a9be5b827eb..a49c322bdbe9d 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -1065,6 +1065,7 @@ enum { QUIRK_R3DI, QUIRK_R3D, QUIRK_AE5, + QUIRK_AE7, }; #ifdef CONFIG_PCI @@ -1184,6 +1185,7 @@ static const struct snd_pci_quirk ca0132_quirks[] = { SND_PCI_QUIRK(0x1102, 0x0013, "Recon3D", QUIRK_R3D), SND_PCI_QUIRK(0x1102, 0x0018, "Recon3D", QUIRK_R3D), SND_PCI_QUIRK(0x1102, 0x0051, "Sound Blaster AE-5", QUIRK_AE5), + SND_PCI_QUIRK(0x1102, 0x0081, "Sound Blaster AE-7", QUIRK_AE7), {} }; -- 2.25.1

1 0

[PATCH AUTOSEL 5.8 090/101] ALSA: hda/ca0132 - Add AE-7 microphone selection commands.
by Sasha Levin 18 Oct '20

18 Oct '20

From: Connor McAdams <conmanx360(a)gmail.com> [ Upstream commit ed93f9750c6c2ed371347d0aac3dcd31cb9cf256 ] Add AE-7 quirk data for setting of microphone. The AE-7 has no front panel connector, so only rear-mic/line-in have new commands. Signed-off-by: Connor McAdams <conmanx360(a)gmail.com> Link: https://lore.kernel.org/r/20200825201040.30339-19-conmanx360@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_ca0132.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index 6dfa864d3fe7b..62a9be5b827eb 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -4675,6 +4675,15 @@ static int ca0132_alt_select_in(struct hda_codec *codec) ca0113_mmio_command_set(codec, 0x30, 0x28, 0x00); tmp = FLOAT_THREE; break; + case QUIRK_AE7: + ca0113_mmio_command_set(codec, 0x30, 0x28, 0x00); + tmp = FLOAT_THREE; + chipio_set_conn_rate(codec, MEM_CONNID_MICIN2, + SR_96_000); + chipio_set_conn_rate(codec, MEM_CONNID_MICOUT2, + SR_96_000); + dspio_set_uint_param(codec, 0x80, 0x01, FLOAT_ZERO); + break; default: tmp = FLOAT_ONE; break; @@ -4720,6 +4729,14 @@ static int ca0132_alt_select_in(struct hda_codec *codec) case QUIRK_AE5: ca0113_mmio_command_set(codec, 0x30, 0x28, 0x00); break; + case QUIRK_AE7: + ca0113_mmio_command_set(codec, 0x30, 0x28, 0x3f); + chipio_set_conn_rate(codec, MEM_CONNID_MICIN2, + SR_96_000); + chipio_set_conn_rate(codec, MEM_CONNID_MICOUT2, + SR_96_000); + dspio_set_uint_param(codec, 0x80, 0x01, FLOAT_ZERO); + break; default: break; } @@ -4729,7 +4746,10 @@ static int ca0132_alt_select_in(struct hda_codec *codec) if (ca0132_quirk(spec) == QUIRK_R3DI) chipio_set_conn_rate(codec, 0x0F, SR_96_000); - tmp = FLOAT_ZERO; + if (ca0132_quirk(spec) == QUIRK_AE7) + tmp = FLOAT_THREE; + else + tmp = FLOAT_ZERO; dspio_set_uint_param(codec, 0x80, 0x00, tmp); switch (ca0132_quirk(spec)) { -- 2.25.1

1 0

[PATCH AUTOSEL 5.9 099/111] ASoC: Intel: sof_rt5682: override quirk data for tgl_max98373_rt5682
by Sasha Levin 18 Oct '20

18 Oct '20

From: Sathyanarayana Nujella <sathyanarayana.nujella(a)intel.com> [ Upstream commit 3e1734b64ce786c54dc98adcfe67941e6011d735 ] A Chrome System based on tgl_max98373_rt5682 has different SSP interface configurations. Using DMI data of this variant DUT, override quirk data. Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella(a)intel.com> Signed-off-by: Mac Chiang <mac.chiang(a)intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20200821195603.215535-13-pierre-louis.bossart@lin… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/intel/boards/sof_rt5682.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c index 0129d23694ed5..9a6f10ede427e 100644 --- a/sound/soc/intel/boards/sof_rt5682.c +++ b/sound/soc/intel/boards/sof_rt5682.c @@ -119,6 +119,19 @@ static const struct dmi_system_id sof_rt5682_quirk_table[] = { .driver_data = (void *)(SOF_RT5682_MCLK_EN | SOF_RT5682_SSP_CODEC(0)), }, + { + .callback = sof_rt5682_quirk_cb, + .matches = { + DMI_MATCH(DMI_PRODUCT_FAMILY, "Google_Volteer"), + DMI_MATCH(DMI_PRODUCT_NAME, "Terrador"), + }, + .driver_data = (void *)(SOF_RT5682_MCLK_EN | + SOF_RT5682_SSP_CODEC(0) | + SOF_SPEAKER_AMP_PRESENT | + SOF_MAX98373_SPEAKER_AMP_PRESENT | + SOF_RT5682_SSP_AMP(2) | + SOF_RT5682_NUM_HDMIDEV(4)), + }, {} }; -- 2.25.1

1 0

[PATCH AUTOSEL 5.9 098/111] ASoC: SOF: Add topology filename override based on dmi data match
by Sasha Levin 18 Oct '20

18 Oct '20

From: Sathyanarayana Nujella <sathyanarayana.nujella(a)intel.com> [ Upstream commit 5253a73d567dcd75e62834ff5f502ea9470e5722 ] Add topology filename override based on system DMI data matching, typically to account for a different hardware layout. In ACPI based systems, the tplg_filename is pre-defined in an ACPI machine table. When a DMI quirk is detected, the sof_pdata->tplg_filename is not set with the hard-coded ACPI value, and instead is set with the DMI-specific filename. Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella(a)intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20200821195603.215535-14-pierre-louis.bossart@lin… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda.c | 8 +++++++- sound/soc/sof/sof-pci-dev.c | 24 ++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 1 deletion(-) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index 63ca920c8e6e0..7152e6d1cf673 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -1179,7 +1179,13 @@ void hda_machine_select(struct snd_sof_dev *sdev) mach = snd_soc_acpi_find_machine(desc->machines); if (mach) { - sof_pdata->tplg_filename = mach->sof_tplg_filename; + /* + * If tplg file name is overridden, use it instead of + * the one set in mach table + */ + if (!sof_pdata->tplg_filename) + sof_pdata->tplg_filename = mach->sof_tplg_filename; + sof_pdata->machine = mach; if (mach->link_mask) { diff --git a/sound/soc/sof/sof-pci-dev.c b/sound/soc/sof/sof-pci-dev.c index aa3532ba14349..f3a8140773db5 100644 --- a/sound/soc/sof/sof-pci-dev.c +++ b/sound/soc/sof/sof-pci-dev.c @@ -35,8 +35,28 @@ static int sof_pci_debug; module_param_named(sof_pci_debug, sof_pci_debug, int, 0444); MODULE_PARM_DESC(sof_pci_debug, "SOF PCI debug options (0x0 all off)"); +static const char *sof_override_tplg_name; + #define SOF_PCI_DISABLE_PM_RUNTIME BIT(0) +static int sof_tplg_cb(const struct dmi_system_id *id) +{ + sof_override_tplg_name = id->driver_data; + return 1; +} + +static const struct dmi_system_id sof_tplg_table[] = { + { + .callback = sof_tplg_cb, + .matches = { + DMI_MATCH(DMI_PRODUCT_FAMILY, "Google_Volteer"), + DMI_MATCH(DMI_PRODUCT_NAME, "Terrador"), + }, + .driver_data = "sof-tgl-rt5682-ssp0-max98373-ssp2.tplg", + }, + {} +}; + static const struct dmi_system_id community_key_platforms[] = { { .ident = "Up Squared", @@ -347,6 +367,10 @@ static int sof_pci_probe(struct pci_dev *pci, sof_pdata->tplg_filename_prefix = sof_pdata->desc->default_tplg_path; + dmi_check_system(sof_tplg_table); + if (sof_override_tplg_name) + sof_pdata->tplg_filename = sof_override_tplg_name; + #if IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE) /* set callback to enable runtime_pm */ sof_pdata->sof_probe_complete = sof_pci_probe_complete; -- 2.25.1

1 0

[PATCH AUTOSEL 5.9 097/111] ALSA: hda/ca0132 - Add new quirk ID for SoundBlaster AE-7.
by Sasha Levin 18 Oct '20

18 Oct '20

From: Connor McAdams <conmanx360(a)gmail.com> [ Upstream commit 620f08eea6d6961b789af3fa3ea86725c8c93ece ] Add a new PCI subsystem ID for the SoundBlaster AE-7 card. Signed-off-by: Connor McAdams <conmanx360(a)gmail.com> Link: https://lore.kernel.org/r/20200825201040.30339-11-conmanx360@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_ca0132.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index c68669911de0a..a3eecdf9185e8 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -1065,6 +1065,7 @@ enum { QUIRK_R3DI, QUIRK_R3D, QUIRK_AE5, + QUIRK_AE7, }; #ifdef CONFIG_PCI @@ -1184,6 +1185,7 @@ static const struct snd_pci_quirk ca0132_quirks[] = { SND_PCI_QUIRK(0x1102, 0x0013, "Recon3D", QUIRK_R3D), SND_PCI_QUIRK(0x1102, 0x0018, "Recon3D", QUIRK_R3D), SND_PCI_QUIRK(0x1102, 0x0051, "Sound Blaster AE-5", QUIRK_AE5), + SND_PCI_QUIRK(0x1102, 0x0081, "Sound Blaster AE-7", QUIRK_AE7), {} }; -- 2.25.1

1 0

[PATCH AUTOSEL 5.9 096/111] ALSA: hda/ca0132 - Add AE-7 microphone selection commands.
by Sasha Levin 18 Oct '20

18 Oct '20

From: Connor McAdams <conmanx360(a)gmail.com> [ Upstream commit ed93f9750c6c2ed371347d0aac3dcd31cb9cf256 ] Add AE-7 quirk data for setting of microphone. The AE-7 has no front panel connector, so only rear-mic/line-in have new commands. Signed-off-by: Connor McAdams <conmanx360(a)gmail.com> Link: https://lore.kernel.org/r/20200825201040.30339-19-conmanx360@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_ca0132.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index b7dbf2e7f77af..c68669911de0a 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -4675,6 +4675,15 @@ static int ca0132_alt_select_in(struct hda_codec *codec) ca0113_mmio_command_set(codec, 0x30, 0x28, 0x00); tmp = FLOAT_THREE; break; + case QUIRK_AE7: + ca0113_mmio_command_set(codec, 0x30, 0x28, 0x00); + tmp = FLOAT_THREE; + chipio_set_conn_rate(codec, MEM_CONNID_MICIN2, + SR_96_000); + chipio_set_conn_rate(codec, MEM_CONNID_MICOUT2, + SR_96_000); + dspio_set_uint_param(codec, 0x80, 0x01, FLOAT_ZERO); + break; default: tmp = FLOAT_ONE; break; @@ -4720,6 +4729,14 @@ static int ca0132_alt_select_in(struct hda_codec *codec) case QUIRK_AE5: ca0113_mmio_command_set(codec, 0x30, 0x28, 0x00); break; + case QUIRK_AE7: + ca0113_mmio_command_set(codec, 0x30, 0x28, 0x3f); + chipio_set_conn_rate(codec, MEM_CONNID_MICIN2, + SR_96_000); + chipio_set_conn_rate(codec, MEM_CONNID_MICOUT2, + SR_96_000); + dspio_set_uint_param(codec, 0x80, 0x01, FLOAT_ZERO); + break; default: break; } @@ -4729,7 +4746,10 @@ static int ca0132_alt_select_in(struct hda_codec *codec) if (ca0132_quirk(spec) == QUIRK_R3DI) chipio_set_conn_rate(codec, 0x0F, SR_96_000); - tmp = FLOAT_ZERO; + if (ca0132_quirk(spec) == QUIRK_AE7) + tmp = FLOAT_THREE; + else + tmp = FLOAT_ZERO; dspio_set_uint_param(codec, 0x80, 0x00, tmp); switch (ca0132_quirk(spec)) { -- 2.25.1

1 0

dcef48f "add support for AMD acp microphone devices" can break pulseaudio
by GitHub issues - opened 18 Oct '20

18 Oct '20

alsa-project/alsa-ucm-conf issue #54 was opened from danielrparks: I recently upgraded alsa-ucm-conf from 1.2.3 to 1.2.4 on Arch Linux, and now pulseaudio fails to initialize my sound card. This system is a Dell Inspiron 7405 with a Ryzen 7 4700U and a Realtek ALC3204 sound card. The microphone is handled by the audio co-processor. Pulseaudio generates the following error: ``` Failed to find a working profile. Failed to load module "module-alsa-card" (argument: "device_id="1" name="pci-0000_03_00.6" card_name="alsa_card.pci-0000_03_00.6" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1""): initialization failed. ``` [notworking-journal.txt](https://github.com/alsa-project/alsa-ucm-conf/files… [working-pacmd-list-sinks.txt](https://github.com/alsa-project/alsa-ucm-conf… I did a git bisect and got this: ``` dcef48f13d4f5db79b006755074940b94730a883 is the first bad commit commit dcef48f13d4f5db79b006755074940b94730a883 Author: Jaroslav Kysela <perex(a)perex.cz> Date: Wed Jun 24 13:39:07 2020 +0200 HDA-Intel: add support for AMD acp microphone devices - move the generic HDA code from sof-hda-dsp to HDA-Intel - add generic codecs/hda/hdmi.conf Signed-off-by: Jaroslav Kysela <perex(a)perex.cz> ucm2/HDA-Intel/HDA-Capture-value.conf | 4 + ucm2/HDA-Intel/HDA-Intel.conf | 28 +++++++ ucm2/HDA-Intel/Hdmi.conf | 37 +++++++++ ucm2/HDA-Intel/HiFi-acp.conf | 8 ++ ucm2/HDA-Intel/HiFi-analog.conf | 133 +++++++++++++++++++++++++++++++ ucm2/HDA-Intel/HiFi.conf | 32 ++++++++ ucm2/HDA-Intel/init.conf | 39 +++++++++ ucm2/codecs/hda/hdmi.conf | 25 ++++++ ucm2/module/lib/linked.conf | 3 + ucm2/module/snd_acp3x_rn.conf | 1 + ucm2/sof-hda-dsp/HDA-Capture-value.conf | 4 - ucm2/sof-hda-dsp/Hdmi.conf | 78 +++++------------- ucm2/sof-hda-dsp/HiFi.conf | 135 +------------------------------- 13 files changed, 331 insertions(+), 196 deletions(-) create mode 100644 ucm2/HDA-Intel/HDA-Capture-value.conf create mode 100644 ucm2/HDA-Intel/HDA-Intel.conf create mode 100644 ucm2/HDA-Intel/Hdmi.conf create mode 100644 ucm2/HDA-Intel/HiFi-acp.conf create mode 100644 ucm2/HDA-Intel/HiFi-analog.conf create mode 100644 ucm2/HDA-Intel/HiFi.conf create mode 100644 ucm2/HDA-Intel/init.conf create mode 100644 ucm2/codecs/hda/hdmi.conf create mode 100644 ucm2/module/lib/linked.conf create mode 120000 ucm2/module/snd_acp3x_rn.conf delete mode 100644 ucm2/sof-hda-dsp/HDA-Capture-value.conf ``` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/54 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Add Slovak translation
by GitHub pull_request - opened 18 Oct '20

18 Oct '20

alsa-project/alsa-utils pull request #68 was opened from jose1711: Request URL : https://github.com/alsa-project/alsa-utils/pull/68 Patch URL : https://github.com/alsa-project/alsa-utils/pull/68.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Add amixer --view, to filter playback, capture or all
by GitHub issues - edited 18 Oct '20

18 Oct '20

alsa-project/alsa-utils issue #67 was edited from jidanni: alsamixer has ``` -V, --view <mode> Select the starting view mode, either playback, capture or all. ``` Perhaps amixer could also have something similar, e.g., so that ``` $ amixer --view capture ``` would only dump the capture related settings. Currently one could say that ``` $ amixer --view all ``` is the default. Issue URL : https://github.com/alsa-project/alsa-utils/issues/67 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Add amixer --view, to filter playback, capture or all
by GitHub issues - opened 18 Oct '20

18 Oct '20

alsa-project/alsa-utils issue #67 was opened from jidanni: alsamixer has ``` -V, --view <mode> Select the starting view mode, either playback, capture or all. ``` Perhaps amixer could also have something similar,' e.g., so that ``` $ amixer --view capture ``` would only dump the capture related settings. Currently one could say that ``` $ amixer --view all ``` is the default. Issue URL : https://github.com/alsa-project/alsa-utils/issues/67 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Fix grammar mess.
by GitHub pull_request - opened 18 Oct '20

18 Oct '20

alsa-project/alsa-utils pull request #66 was opened from jidanni: Fix grammar mess. Request URL : https://github.com/alsa-project/alsa-utils/pull/66 Patch URL : https://github.com/alsa-project/alsa-utils/pull/66.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

arecord/aplay man page should separate the options into three lists…
by GitHub issues - edited 18 Oct '20

18 Oct '20

alsa-project/alsa-utils issue #65 was edited from jidanni: The arecord/aplay man page should perhaps separate the options into three lists 1. ones that affect recording, 2. ones that affect playing, 2. and ones that affect both. Issue URL : https://github.com/alsa-project/alsa-utils/issues/65 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

arecord/aplay man page should separate the options into three lists…
by GitHub issues - opened 18 Oct '20

18 Oct '20

alsa-project/alsa-utils issue #65 was opened from jidanni: The arecord/aplay man page should perhaps separate the options into three lists, ones that affect recording, ones that affect playing, and ones that affect both. Issue URL : https://github.com/alsa-project/alsa-utils/issues/65 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

alsamixer: add "restore defaults" keystroke
by GitHub issues - opened 18 Oct '20

18 Oct '20

alsa-project/alsa-utils issue #64 was opened from jidanni: There should be a way to "restore defaults" for all levels for this sound card. And perhaps for each level individually too. Issue URL : https://github.com/alsa-project/alsa-utils/issues/64 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH] ALSA: hda/ca0132: make some const arrays static, makes object smaller
by Colin King 17 Oct '20

17 Oct '20

From: Colin Ian King <colin.king(a)canonical.com> Don't populate const arrays on the stack but instead make them static. Makes the object code smaller by 57 bytes. Before: text data bss dec hex filename 173256 38016 192 211464 33a08 sound/pci/hda/patch_ca0132.o After: text data bss dec hex filename 172879 38336 192 211407 339cf sound/pci/hda/patch_ca0132.o (gcc version 10.2.0) Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/pci/hda/patch_ca0132.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index 2b38b2a716a1..e0c38f2735c6 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -7910,8 +7910,12 @@ static void ae7_post_dsp_asi_stream_setup(struct hda_codec *codec) static void ae7_post_dsp_pll_setup(struct hda_codec *codec) { - const unsigned int addr[] = { 0x41, 0x45, 0x40, 0x43, 0x51 }; - const unsigned int data[] = { 0xc8, 0xcc, 0xcb, 0xc7, 0x8d }; + static const unsigned int addr[] = { + 0x41, 0x45, 0x40, 0x43, 0x51 + }; + static const unsigned int data[] = { + 0xc8, 0xcc, 0xcb, 0xc7, 0x8d + }; unsigned int i; for (i = 0; i < ARRAY_SIZE(addr); i++) { @@ -7925,10 +7929,12 @@ static void ae7_post_dsp_pll_setup(struct hda_codec *codec) static void ae7_post_dsp_asi_setup_ports(struct hda_codec *codec) { struct ca0132_spec *spec = codec->spec; - const unsigned int target[] = { 0x0b, 0x04, 0x06, 0x0a, 0x0c, 0x11, - 0x12, 0x13, 0x14 }; - const unsigned int data[] = { 0x12, 0x00, 0x48, 0x05, 0x5f, 0xff, - 0xff, 0xff, 0x7f }; + static const unsigned int target[] = { + 0x0b, 0x04, 0x06, 0x0a, 0x0c, 0x11, 0x12, 0x13, 0x14 + }; + static const unsigned int data[] = { + 0x12, 0x00, 0x48, 0x05, 0x5f, 0xff, 0xff, 0xff, 0x7f + }; unsigned int i; mutex_lock(&spec->chipio_mutex); -- 2.27.0

2 1

[PATCH v2] sound: sparc: dbri: fix repeated word 'the'
by Randy Dunlap 17 Oct '20

17 Oct '20

Change the duplicated word "the" to "Then the". Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: alsa-devel(a)alsa-project.org Cc: Joe Perches <joe(a)perches.com> --- v2: use "Then the" instead of just "The". (Joe Perches) sound/sparc/dbri.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20201016.orig/sound/sparc/dbri.c +++ linux-next-20201016/sound/sparc/dbri.c @@ -620,7 +620,7 @@ A circular command buffer is used here. while another can be executed. The scheme works by adding two WAIT commands after each sent batch of commands. When the next batch is prepared it is added after the WAIT commands then the WAITs are replaced with single JUMP -command to the new batch. The the DBRI is forced to reread the last WAIT +command to the new batch. Then the DBRI is forced to reread the last WAIT command (replaced by the JUMP by then). If the DBRI is still executing previous commands the request to reread the WAIT command is ignored.

2 1

Re: [PATCH] ASoC: Intel: boards: Add CML_RT1015 m/c driver
by Mark Brown 16 Oct '20

16 Oct '20

On Sat, Oct 17, 2020 at 12:02:24AM +0800, matsufan(a)gmail.com wrote: > +<<<<<<< HEAD > obj-$(CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH) += snd-soc-cml_rt1011_rt5682.o > +======= > +obj-$(CONFIG_SND_SOC_INTEL_SOF_CML_RT1011_RT5682_MACH) += cml_rt1011_rt5682.o > +obj-$(CONFIG_SND_SOC_INTEL_SOF_CML_RT1015_RT5682_MACH) += cml_rt1015_rt5682.o > +>>>>>>> 955c356... CHROMIUM: ASoC: Intel: boards: Add CML_RT1015 m/c driver There's an unresolved conflict here :/

3 3

Discover a microphone device, to later discover if it is receiving input
by info 16 Oct '20

16 Oct '20

Hi all, I am writing a program that aims to auto-discover the microphone device that the user is speaking into. I started off by querying device hints and collected all devices with the IO types of null, since I have not found any devices with the type of Input. I am puzzled how it is possible that there is no Input, where a microphone device should not be able to emit sound. This is the list on my particular machine: Name of device: sysdefault:CARD=SB Description of device: HDA ATI SB, ALC892 Analog Default Audio Device I/O type of device: (null) Name of device: front:CARD=SB,DEV=0 Description of device: HDA ATI SB, ALC892 Analog Front speakers I/O type of device: (null) Name of device: surround21:CARD=SB,DEV=0 Description of device: HDA ATI SB, ALC892 Analog 2.1 Surround output to Front and Subwoofer speakers I/O type of device: Output Name of device: surround41:CARD=SB,DEV=0 Description of device: HDA ATI SB, ALC892 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers I/O type of device: Output Name of device: surround50:CARD=SB,DEV=0 Description of device: HDA ATI SB, ALC892 Analog 5.0 Surround output to Front, Center and Rear speakers I/O type of device: Output Name of device: surround71:CARD=SB,DEV=0 Description of device: HDA ATI SB, ALC892 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers I/O type of device: Output Name of device: sysdefault:CARD=SB Description of device: HDA ATI SB, ALC892 Analog Default Audio Device I/O type of device: (null) Name of device: front:CARD=SB,DEV=0 Description of device: HDA ATI SB, ALC892 Analog Front speakers I/O type of device: (null) Now, I am more puzzled, because none of them is a microphone device explicitly. How can my program determine which of them is actually a microphone? Also, why are devices are duplicated in the output from snd_device_name_hint()? The very first device is also repeated as the 2nd last one... Regards, Alex

3 6

[PATCH v3 00/13] Audio graph card updates and usage with Tegra210 audio
by Sameer Pujar 16 Oct '20

16 Oct '20

Summary of changes: * Support multiple instances of a component. For example there can be multiple I2S devices which can use the same component driver. * Support open platforms with empty Codec endpoint. Customers can plug their own HW and can populate codec endpoint. * In a component model there can be many components which can be connected togethe. In such cases Identify no-pcm DPCM DAI links which can be used in BE<->BE connections. * Add Tegra audio graph driver which is based on generic audio graph driver and specific customizations are done in Tegra driver. * This pushes DT support for Tegra210 based platforms which uses audio-graph card and above enhancements. The series is based on following references where DPCM usgae for Tegra Audio and simple-card driver proposal were discussed. * https://lkml.org/lkml/2020/4/30/519 (DPCM for Tegra) * https://lkml.org/lkml/2020/6/27/4 (simple-card driver) Changelog ========= v1 -> v2 -------- * Re-organized ports/endpoints description for ADMAIF and XBAR. Updated DT patches accordingly. * After above change, multiple Codec endpoint support is not required and hence dropped for now. This will be considered separately if at all required in future. * Re-ordered patches in the series. v2 -> v3 -------- * Dropped new compatible addition in generic graph driver after reviewing it with Morimoto-san. Instead added Tegra audio graph driver and new compatibles are added in the same. * Added new patches to expose new members for customization in audio graph driver. * Added new patch for Tegra audio graph driver and related documentation. * Minor change in below commit where mutex version of helper is used "ASoC: audio-graph: Identify 'no_pcm' DAI links for DPCM" * DT binding is updated to use the newly exposed compatibles * No changes in other patches Sameer Pujar (13): ASoC: soc-core: Fix component name_prefix parsing ASoC: soc-pcm: Get all BEs along DAPM path ASoC: audio-graph: Use of_node and DAI for DPCM DAI link names ASoC: audio-graph: Identify 'no_pcm' DAI links for DPCM ASoC: audio-graph: Support empty Codec endpoint ASoC: simple-card-utils: Expose new members for asoc_simple_priv ASoC: audio-graph: Update driver as per new exposed members ASoC: audio-graph: Expose helpers from audio graph ASoC: dt-bindings: tegra: Add schema for audio graph card ASoC: tegra: Add audio graph based card driver arm64: defconfig: Enable Tegra audio graph card driver arm64: tegra: Audio graph header for Tegra210 arm64: tegra: Audio graph sound card for Jetson Nano and TX1 .../sound/nvidia,tegra-audio-graph-card.yaml | 67 +++++ .../boot/dts/nvidia/tegra210-audio-graph.dtsi | 138 ++++++++++ arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts | 219 ++++++++++++++++ arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 124 +++++++++ arch/arm64/configs/defconfig | 1 + include/sound/graph_card.h | 19 ++ include/sound/simple_card_utils.h | 4 + include/sound/soc.h | 1 + sound/soc/generic/audio-graph-card.c | 92 +++++-- sound/soc/soc-core.c | 3 +- sound/soc/soc-pcm.c | 3 +- sound/soc/tegra/Kconfig | 9 + sound/soc/tegra/Makefile | 2 + sound/soc/tegra/tegra_audio_graph_card.c | 291 +++++++++++++++++++++ 14 files changed, 955 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml create mode 100644 arch/arm64/boot/dts/nvidia/tegra210-audio-graph.dtsi create mode 100644 include/sound/graph_card.h create mode 100644 sound/soc/tegra/tegra_audio_graph_card.c -- 2.7.4

8 33

[PATCH 1/2] MAINTAINERS: Move Kukjin Kim to credits
by Krzysztof Kozlowski 16 Oct '20

16 Oct '20

Kukjin Kim has been maintaining the Samsung ARM architectures since 2010 up to 2016. He contributed many patches for the S3C, S5P and Exynos support. However since 2016 there is little activity from him on the LKML [1] so move his name to the CREDITS. Dear Kukjin, thank you for all the effort you put in to the upstream Samsung support. [1] https://lore.kernel.org/lkml/?q=f%3A%22Kukjin+Kim%22 Cc: Kukjin Kim <kgene(a)kernel.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Olof Johansson <olof(a)lixom.net> Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> --- CREDITS | 4 ++++ MAINTAINERS | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/CREDITS b/CREDITS index cb02b9923a52..5df027e12ff7 100644 --- a/CREDITS +++ b/CREDITS @@ -1910,6 +1910,10 @@ S: 660 Harvard Ave. #7 S: Santa Clara, CA 95051 S: USA +N: Kukjin Kim +E: kgene(a)kernel.org +D: Samsung S3C, S5P and Exynos ARM architectures + N: Russell King E: rmk(a)arm.linux.org.uk D: Linux/arm integrator, maintainer & hacker diff --git a/MAINTAINERS b/MAINTAINERS index 4538378de6f5..c3976803057c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2375,7 +2375,6 @@ F: sound/soc/rockchip/ N: rockchip ARM/SAMSUNG EXYNOS ARM ARCHITECTURES -M: Kukjin Kim <kgene(a)kernel.org> M: Krzysztof Kozlowski <krzk(a)kernel.org> L: linux-arm-kernel(a)lists.infradead.org (moderated for non-subscribers) L: linux-samsung-soc(a)vger.kernel.org @@ -15497,7 +15496,6 @@ F: include/linux/clk/samsung.h F: include/linux/platform_data/clk-s3c2410.h SAMSUNG SPI DRIVERS -M: Kukjin Kim <kgene(a)kernel.org> M: Krzysztof Kozlowski <krzk(a)kernel.org> M: Andi Shyti <andi(a)etezian.org> L: linux-spi(a)vger.kernel.org -- 2.25.1

1 1

Re: [alsa-devel] [PATCH] ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers
by Takashi Iwai 16 Oct '20

16 Oct '20

On Fri, 11 Oct 2019 19:19:36 +0200, Szabolcs Szőke wrote: > > BOSS Katana amplifiers cannot be used for recording or playback if quirks > are applied > > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223 > Signed-off-by: Szabolcs Szőke <szszoke.code(a)gmail.com> Applied now. Thanks. Takashi > > --- > sound/usb/pcm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c > index 33cd26763c0e..daadb0c66eee 100644 > --- a/sound/usb/pcm.c > +++ b/sound/usb/pcm.c > @@ -348,6 +348,9 @@ static int set_sync_ep_implicit_fb_quirk(struct snd_usb_substream *subs, > ep = 0x84; > ifnum = 0; > goto add_sync_ep_from_ifnum; > + case USB_ID(0x0582, 0x01d8): /* BOSS Katana */ > + /* BOSS Katana amplifiers do not need quirks */ > + return 0; > } > > if (attr == USB_ENDPOINT_SYNC_ASYNC && > -- > 2.20.1 >

5 20

More Generic Audio Graph Sound Card idea
by Kuninori Morimoto 16 Oct '20

16 Oct '20

Hi Mark Cc Pierre-Louis, Sameer Current audio-graph-card driver has DPCM support, but it is limited (= Mix/Mux/TDM-split/rate-convert/channel-convert). It was expanded forcibly expanded. Because of it, the connection judgement for normal vs DPCM is tricky. I know Pierre-Louis want to use it for SOF, but something is missing, thus, can't use (?). I know now Sameer is currently trying to expand it now. It is OK for me, but, more expansion in the future will be difficult/buggy. For example supporting many *generic* DPCM and normal connection in the same time will be difficult. I'm thinking below style as new audio-graph-card2. It is not tricky, thus connection judgement for normal vs DSP is easy. Then, code can be more readable (= no guaranty :P) ? I guss "audio-graph-card" and "audio-graph-card2" can have some (= not full) compatible for normal connection. But has no compatible for DPCM connection. I think I need to keep as-is for current audio-graph-card, and create new audio-graph-card2 driver. Because there is users, and card2 implementation will have huge different. Keeping compatible and update will be very difficult or buggy. But what do you think ? Note 1 is that this is just idea for now. I'm very happy to implement it, but it will be after that my all remaining patch was posted/accepted. Note 2 is that I'm not full DPCM analyst. Thus, maybe audio-graph-card2 can solve current connection issue, but might can't for unknown connection case. In such came we need ver3 (?). ------------ image --------------------------- | Front End PCMs | SoC DSP | Back End DAIs | Audio devices | ************* PCM0 <------------> * * <----DAI0-----> Codec Headset * * PCM1 <------------> * * <----DAI1-----> Codec Speakers * DSP * PCM2 <------------> * * <----DAI2-----> MODEM * * PCM3 <------------> * * <----DAI3-----> BT * * * * <----DAI4-----> DMIC * * * * <----DAI5-----> FM ************* ------------ DT sample --------------------------- sound { compatible = "audio-graph-card2"; dais = <&pcm0, &pcm1, &pcm2, &pcm3>; }; front-end { ports { pcm0: port@0 { pcm0_endpoint: endpoint { remote-endpoint = <&dsp_f0>; }; }; pcm1: port@1 { pcm1_endpoint: endpoint { remote-endpoint = <&dsp_f1>; }; }; pcm2: port@2 { pcm2_endpoint: endpoint { remote-endpoint = <&dsp_f2>; }; }; pcm3: port@3 { pcm3_endpoint: endpoint { remote-endpoint = <&dsp_f3>; }; }; }; }; dsp { compatible = "audio-graph-card2-dsp"; ports { /* Front End side */ port@0 { dsp_f0: endpoint { remote-endpoint = <&pcm0>; }; }; port@1 { dsp_f1: endpoint { remote-endpoint = <&pcm1>; }; }; port@2 { dsp_f2: endpoint { remote-endpoint = <&pcm2>; }; }; port@3 { dsp_f3: endpoint { remote-endpoint = <&pcm3>; }; }; /* Back End side */ port@4 { dsp_b0: endpoint { remote-endpoint = <&dai0>; }; }; port@5 { dsp_b1: endpoint { remote-endpoint = <&dai1>; }; }; port@6 { dsp_b2: endpoint { remote-endpoint = <&dai2>; }; }; port@7 { dsp_b3: endpoint { remote-endpoint = <&dai3>; }; }; port@8 { dsp_b4: endpoint { remote-endpoint = <&dai4>; }; }; port@9 { dsp_b5: endpoint { remote-endpoint = <&dai5>; }; }; }; }; back-end { ports { port@0 { dai0: endpoint { remote-endpoint = <&dsp_b0>; }; }; port@1 { dai1: endpoint { remote-endpoint = <&dsp_b1>; }; }; port@2 { dai2: endpoint { remote-endpoint = <&dsp_b2>; }; }; port@3 { dai3: endpoint { remote-endpoint = <&dsp_b3>; }; }; port@4 { dai4: endpoint { remote-endpoint = <&dsp_b4>; }; }; port@5 { dai5: endpoint { remote-endpoint = <&dsp_b5>; }; }; }; };

5 30

amixer: cset: check control is readable before reading it
by GitHub pull_request - opened 15 Oct '20

15 Oct '20

alsa-project/alsa-utils pull request #63 was opened from ViorelSuman: In current implementation cset command will fail on controls which are not readable, ie just writable. Check readable state prior calling snd_ctl_elem_read. Signed-off-by: Viorel Suman <viorel.suman(a)nxp.com> Request URL : https://github.com/alsa-project/alsa-utils/pull/63 Patch URL : https://github.com/alsa-project/alsa-utils/pull/63.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Release change info in release [atom feed] messages?
by GitHub issues - opened 15 Oct '20

15 Oct '20

alsa-project/alsa-lib issue #86 was opened from mxmilkiib: I'm currently working on an software update aggregation system - https://libreav.org/updates - and I'd like to add ALSA itself, but I don't think there is a feed for this other than https://github.com/alsa-project/alsa-lib/releases.atom. However, the releases.atom entries do not contain the Changes summary that is used on [the wiki](https://www.alsa-project.org/wiki/Changes_v1.2.3.1_v1.2.3.2). Might it be possible for the release messages to contain those texts? Issue URL : https://github.com/alsa-project/alsa-lib/issues/86 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

pcm_meter.c issue at s16_update
by Go Peppy 15 Oct '20

15 Oct '20

Hi, It would be great to have a fix/patch from Pavel in the main codebase. I've tested his fix and it worked fine. Just to remind what the issue is - while switching from one web radio station to another there is a high CPU usage for about 20 seconds. Because of that high CPU consumption almost all other processes are blocked. The fix from Pavel helps to avoid this situation. Without the ALSA patch I need to make a custom ALSA build every time I release my software. This is very annoying. Thanks in advance!

3 3

[PATCH] ASoC: Intel: atom: Remove duplicate kconfigs
by Cezary Rojewski 14 Oct '20

14 Oct '20

SND_SST_IPC and its _PCI and _ACPI variants all target sound/soc/intel/atom solution alone. SND_SST_IPC is the core component, required for PCI and ACPI based atom platforms both. _PCI and _ACPI target Merrifield/Edison and Baytrial/Cherrytrail platforms respectively. On top of that, there is an equivalent set of configs targeting the same solution: - SND_SST_ATOM_HIFI2_PLATFORM (core) - SND_SST_ATOM_HIFI2_PLATFORM_PCI - SND_SST_ATOM_HIFI2_PLATFORM_ACPI As both sets do the same job - allow for granular platform selection - remove the duplicate set and rely on SND_SST_ATOM_HIFI2_PLATOFRM_XXX configs alone. Signed-off-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- sound/soc/intel/Kconfig | 18 ------------------ sound/soc/intel/atom/Makefile | 2 +- sound/soc/intel/atom/sst/Makefile | 6 +++--- 3 files changed, 4 insertions(+), 22 deletions(-) diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index d5bae5d1ab6f..a5b446d5af19 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -15,22 +15,6 @@ config SND_SOC_INTEL_SST_TOPLEVEL if SND_SOC_INTEL_SST_TOPLEVEL -config SND_SST_IPC - tristate - # This option controls the IPC core for HiFi2 platforms - -config SND_SST_IPC_PCI - tristate - select SND_SST_IPC - # This option controls the PCI-based IPC for HiFi2 platforms - # (Medfield, Merrifield). - -config SND_SST_IPC_ACPI - tristate - select SND_SST_IPC - # This option controls the ACPI-based IPC for HiFi2 platforms - # (Baytrail, Cherrytrail) - config SND_SOC_INTEL_SST tristate @@ -57,7 +41,6 @@ config SND_SST_ATOM_HIFI2_PLATFORM config SND_SST_ATOM_HIFI2_PLATFORM_PCI tristate "PCI HiFi2 (Merrifield) Platforms" depends on X86 && PCI - select SND_SST_IPC_PCI select SND_SST_ATOM_HIFI2_PLATFORM help If you have a Intel Merrifield/Edison platform, then @@ -70,7 +53,6 @@ config SND_SST_ATOM_HIFI2_PLATFORM_ACPI tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms" default ACPI depends on X86 && ACPI && PCI - select SND_SST_IPC_ACPI select SND_SST_ATOM_HIFI2_PLATFORM select SND_SOC_ACPI_INTEL_MATCH select IOSF_MBI diff --git a/sound/soc/intel/atom/Makefile b/sound/soc/intel/atom/Makefile index a9326d5ec44c..c66f03f5d8d6 100644 --- a/sound/soc/intel/atom/Makefile +++ b/sound/soc/intel/atom/Makefile @@ -6,4 +6,4 @@ snd-soc-sst-atom-hifi2-platform-objs := sst-mfld-platform-pcm.o \ obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM) += snd-soc-sst-atom-hifi2-platform.o # DSP driver -obj-$(CONFIG_SND_SST_IPC) += sst/ +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM) += sst/ diff --git a/sound/soc/intel/atom/sst/Makefile b/sound/soc/intel/atom/sst/Makefile index f17c905df3e2..5761d30a5f9d 100644 --- a/sound/soc/intel/atom/sst/Makefile +++ b/sound/soc/intel/atom/sst/Makefile @@ -3,6 +3,6 @@ snd-intel-sst-core-objs := sst.o sst_ipc.o sst_stream.o sst_drv_interface.o sst_ snd-intel-sst-pci-objs += sst_pci.o snd-intel-sst-acpi-objs += sst_acpi.o -obj-$(CONFIG_SND_SST_IPC) += snd-intel-sst-core.o -obj-$(CONFIG_SND_SST_IPC_PCI) += snd-intel-sst-pci.o -obj-$(CONFIG_SND_SST_IPC_ACPI) += snd-intel-sst-acpi.o +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM) += snd-intel-sst-core.o +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_PCI) += snd-intel-sst-pci.o +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI) += snd-intel-sst-acpi.o -- 2.17.1

3 2

[PATCH 1/2] ASoC: Intel: catpt: Wake up device before configuring SSP port
by Cezary Rojewski 14 Oct '20

14 Oct '20

catpt_dai_pcm_new() invoked during new PCM runtime creation configures SSP by sending IPC to DSP firmware. For that to succeed device needs to be up and running. While components default probing behavior - snd_soc_catpt causing machine board module to load just after it - needs no changes, machine board's module may be unloaded and re-loaded at a different time e.g.: when catpt is already asleep. Wake device explicitly in catpt_dai_pcm_new() to ensure communication is established before sending any IPCs, enabling those advanced scenarios in the process. Signed-off-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- In short, this allows for following scenario (which user usually do not touch): 1. modprobe snd_soc_catpt // core driver 2. modprobe snd_soc_sst_broadwell // machine board driver 3. wait for snd_soc_catpt to suspend (~2s) 4. rmmod snd_soc_sst_broadwell 5. modprobe snd_soc_sst_broadwell Without the 3. everything works just fine but let's be more flexible here. Right now, -110 (timeout) will occur as device will simply be asleep. To allow for this advanced scenario, pm_runtime manipulation is required. memcmp check is to prevent unnecessary operations from occurring. sound/soc/intel/catpt/pcm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sound/soc/intel/catpt/pcm.c b/sound/soc/intel/catpt/pcm.c index f78018c857b8..ba653ebea7d1 100644 --- a/sound/soc/intel/catpt/pcm.c +++ b/sound/soc/intel/catpt/pcm.c @@ -667,7 +667,17 @@ static int catpt_dai_pcm_new(struct snd_soc_pcm_runtime *rtm, break; } + /* see if this is a new configuration */ + if (!memcmp(&cdev->devfmt[devfmt.iface], &devfmt, sizeof(devfmt))) + return 0; + + pm_runtime_get_sync(cdev->dev); + ret = catpt_ipc_set_device_format(cdev, &devfmt); + + pm_runtime_mark_last_busy(cdev->dev); + pm_runtime_put_autosuspend(cdev->dev); + if (ret) return CATPT_IPC_ERROR(ret); -- 2.17.1

2 2

[PATCH 0/3] ASoC: sof: cleanup Kconfig files
by Randy Dunlap 14 Oct '20

14 Oct '20

Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Cc: Daniel Baluta <daniel.baluta(a)nxp.com> Cc: sound-open-firmware(a)alsa-project.org Cc: alsa-devel(a)alsa-project.org Some general editing of sound/soc/sof/ Kconfig files: [PATCH 1/3] ASoC: sof: imx: fix Kconfig punctuation [PATCH 2/3] ASoC: sof: intel: fix Kconfig punctuation and wording [PATCH 3/3] ASoC: sof: Kconfig: fix Kconfig punctuation and wording sound/soc/sof/Kconfig | 42 +++++++++++------------ sound/soc/sof/imx/Kconfig | 10 ++--- sound/soc/sof/intel/Kconfig | 62 +++++++++++++++++----------------- 3 files changed, 57 insertions(+), 57 deletions(-)

2 5

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Pavel Machek 14 Oct '20

14 Oct '20

On Wed 2020-10-14 10:22:01, Udo van den Heuvel wrote: > On 14-10-2020 10:11, Pavel Machek wrote: > >> It's a computer, not a disco-light or anything like that. > > > > And you probably have numlock LED. > > On the case? no way. > It is on the keyboard, a separate device, and already has a function. > We also have a caps lock LED and scroll lock LED there, with separate > functions. > I do not need 'extra' functionality for those. > > > Additional config options have costs, too, and we don't want to > > support gazillion config options. > > That is not the issue. > One should have thought about stuff beforehand. We did. And decided this is best solution. > The non-selectability is not my fault. It also does not affect you in any way. Feel free to go to the mic LED discussion to see why we did it like this. Then you can come up with better solution for problem at hand. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

1 0

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Randy Dunlap 14 Oct '20

14 Oct '20

On 10/13/20 10:16 PM, Udo van den Heuvel wrote: > On 14-10-2020 07:07, Randy Dunlap wrote: >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote: > >>> I.e.: it looks like I will lose some funcionality when I disable >>> SND_HDA_CODEC_REALTEK. >> >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK >> with no LEDS. That driver apparently wants LEDS. > > Thanks but why have I gone for years without LEDS? > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are > visible, usable, etc). > > Please make this selectable instead of forcing more bulk into my kernel. > > Kind regards, > Udo Hi Takashi, Regarding commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc Author: Takashi Iwai <tiwai(a)suse.de> Date: Thu Jun 18 13:08:31 2020 +0200 ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev and this Kconfig entry: config SND_HDA_CODEC_REALTEK tristate "Build Realtek HD-audio codec support" select SND_HDA_GENERIC select SND_HDA_GENERIC_LEDS it seems that LED support is not always wanted (please see above). I.e., user(s) would like to build a kernel without LED support at all. Can you make it a build option? thanks. -- ~Randy

3 8

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Pavel Machek 14 Oct '20

14 Oct '20

On Wed 2020-10-14 10:05:42, Udo van den Heuvel wrote: > On 14-10-2020 09:58, Pavel Machek wrote: > > Contrary to his claims, Udo very probably has LEDs in his systems... > > We have a visible power LED. > WE have a HDD LED. > The board has LEDs, yes, but the SilverStone Fortress FT02 hides them > fairly well. > I did not ask for LEDs nor need them this way. > It's a computer, not a disco-light or anything like that. And you probably have numlock LED. > Whether the code is big or not does not matter, it is a matter of being > able to select what one needs without getting bothered with other code > that will do nothing. No. Additional config options have costs, too, and we don't want to support gazillion config options. LED core should be small enough that it does not matter. Sound was inventing its own "tiny LED core" before. > So please consider. I did. Answer is no. Please accept it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

1 0

[PATCH 1/2] Asoc: qcom: lpass-cpu: Fix clock disable failure
by Srinivasa Rao Mandadapu 14 Oct '20

14 Oct '20

From: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Disable MI2S bit clock from PAUSE/STOP/SUSPEND usecase instead of shutdown time. Acheive this by invoking clk_disable_unprepare API from cpu daiops shutdown to cpu daiops trigger. This Fix is update to the below patch. https://lore.kernel.org/patchwork/patch/1308101/ Signed-off-by: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Signed-off-by: Srinivasa Rao Mandadapu <srivasam(a)codeaurora.org> --- sound/soc/qcom/lpass-cpu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c index ba2aca3..2dfb921 100644 --- a/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-cpu.c @@ -88,8 +88,6 @@ static void lpass_cpu_daiops_shutdown(struct snd_pcm_substream *substream, { struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai); - clk_disable_unprepare(drvdata->mi2s_bit_clk[dai->driver->id]); - clk_disable_unprepare(drvdata->mi2s_osr_clk[dai->driver->id]); } @@ -324,6 +322,7 @@ static int lpass_cpu_daiops_trigger(struct snd_pcm_substream *substream, if (ret) dev_err(dai->dev, "error writing to i2sctl reg: %d\n", ret); + clk_disable_unprepare(drvdata->mi2s_bit_clk[dai->driver->id]); break; } -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

2 2

Accessing pending hw_params in SND_PCM_HOOK_TYPE_HW_PARAMS call back
by alsa＠scripple.org 13 Oct '20

13 Oct '20

Hello, I'll try again with a more specific question. Is there a way one can access the hw_params that cause the SND_PCM_HOOK_TYPE_HW_PARAMS call back to be called inside the call back function? The hook only provides access to the snd_pcm_t object, but all the public calls to get hw_params fail because it's not in a prepared state yet. If there isn't a way to get them now could we please add the ability with a patch like the one below? With this patch a call to snd_pcm_hook_get_hw_params provides access to the pending hw_params structure and the pending parameters can be accessed with standard calls like snd_pcm_hw_params_get_channels. Hopefully I'm just missing how to get them without the patch, but if not they really should be made accessible. diff --git a/alsa-lib-1.1.8/include/pcm.h b/pcm.h index 5b07823..0cf5dca 100644 --- a/alsa-lib-1.1.8/include/pcm.h +++ b/pcm.h @@ -1181,6 +1181,7 @@ typedef struct _snd_pcm_hook snd_pcm_hook_t; /** PCM hook callback function */ typedef int (*snd_pcm_hook_func_t)(snd_pcm_hook_t *hook); snd_pcm_t *snd_pcm_hook_get_pcm(snd_pcm_hook_t *hook); +snd_pcm_hw_params_t *snd_pcm_hook_get_hw_params(snd_pcm_hook_t *hook); void *snd_pcm_hook_get_private(snd_pcm_hook_t *hook); void snd_pcm_hook_set_private(snd_pcm_hook_t *hook, void *private_data); int snd_pcm_hook_add(snd_pcm_hook_t **hookp, snd_pcm_t *pcm, diff --git a/alsa-lib-1.1.8/src/pcm/pcm_hooks.c b/pcm_hooks.c index 4416d36..f56c3af 100644 --- a/alsa-lib-1.1.8/src/pcm/pcm_hooks.c +++ b/pcm_hooks.c @@ -38,6 +38,7 @@ const char *_snd_module_pcm_hooks = ""; #ifndef DOC_HIDDEN struct _snd_pcm_hook { snd_pcm_t *pcm; + snd_pcm_hw_params_t *params; snd_pcm_hook_func_t func; void *private_data; struct list_head list; @@ -117,6 +118,7 @@ static int snd_pcm_hooks_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t *params) return err; list_for_each_safe(pos, next, &h->hooks[SND_PCM_HOOK_TYPE_HW_PARAMS]) { snd_pcm_hook_t *hook = list_entry(pos, snd_pcm_hook_t, list); + hook->params = params; err = hook->func(hook); if (err < 0) return err; @@ -563,6 +565,17 @@ snd_pcm_t *snd_pcm_hook_get_pcm(snd_pcm_hook_t *hook) return hook->pcm; } +/** + * \brief Get hw_params handle for a PCM hook + * \param hook PCM hook handle + * \return hw_params handle + */ +snd_pcm_hw_params_t *snd_pcm_hook_get_hw_params(snd_pcm_hook_t *hook) +{ + assert(hook); + return hook->params; +} + /** * \brief Get callback function private data for a PCM hook * \param hook PCM hook handle @@ -609,6 +622,7 @@ int snd_pcm_hook_add(snd_pcm_hook_t **hookp, snd_pcm_t *pcm, if (!h) return -ENOMEM; h->pcm = pcm; + h->params = NULL; h->func = func; h->private_data = private_data; hooks = pcm->private_data;

1 0

[PATCH v2 0/6] Ancillary bus implementation and SOF multi-client support
by Dave Ertman 13 Oct '20

13 Oct '20

Version 2 of this patchset is being pushed out when there are still some issues up in the air. This push, along with the changes in the change log below, is to fix the broken distribution among mailing lists and individuals of the first version submission. At least two items still under discussion are: Final name for the bus Documentation of sysfs directories Brief history of Ancillary Bus ============================== The ancillary bus code was originally submitted upstream as virtual bus, and was submitted through the netdev tree.  This process generated up to v4.  This discussion can be found here: https://lore.kernel.org/netdev/20191111192219.30259-1-jeffrey.t.kirsher@int… At this point, GregKH requested that we take the review and revision process to an internal mailing list and garner the buy-in of a respected kernel contributor. The ancillary bus (then known as virtual bus) was originally submitted along with implementation code for the ice driver and irdma drive, causing the complication of also having dependencies in the rdma tree. This new submission is utilizing an ancillary bus consumer in only the sound driver tree to create the initial implementation and a single user. Since implementation work has started on this patch set, there have been multiple inquiries about the time frame of its completion. It appears that there will be numerous consumers of this functionality. The process of internal review and implementation using the sound drivers generated 19 internal versions.  The changes, including the name change from virtual bus to ancillary bus, from these versions can be summarized as the following: - Fixed compilation and checkpatch errors - Improved documentation to address the motivation for virtual bus. - Renamed virtual bus to ancillary bus - increased maximum device name size - Correct order in Kconfig and Makefile - removed the mid-layer adev->release layer for device unregister - pushed adev->id management to parent driver - all error paths out of ancillary_device_register return error code - all error paths out of ancillary_device_register use put_device - added adev->name element - modname in register cannot be NULL - added KBUILD_MODNAME as prefix for match_name - push adev->id responsibility to registering driver - uevent now parses adev->dev name - match_id function now parses adev->dev name - changed drivers probe function to also take an ancillary_device_id param - split ancillary_device_register into device_initialize and device_add - adjusted what is done in device_initialize and device_add - change adev to ancildev and adrv to ancildrv - change adev to ancildev in documentation ========================== Introduces the ancillary bus implementation along with the example usage in the Sound Open Firmware(SOF) audio driver. In some subsystems, the functionality of the core device (PCI/ACPI/other) may be too complex for a single device to be managed as a monolithic block or a part of the functionality might need to be exposed to a different subsystem. Splitting the functionality into smaller orthogonal devices makes it easier to manage data, power management and domain-specific communication with the hardware. Also, common ancillary_device functionality across primary devices can be handled by a common ancillary_device. A key requirement for such a split is that there is no dependency on a physical bus, device, register accesses or regmap support. These individual devices split from the core cannot live on the platform bus as they are not physical devices that are controlled by DT/ACPI. The same argument applies for not using MFD in this scenario as it relies on individual function devices being physical devices that are DT enumerated. An example for this kind of requirement is the audio subsystem where a single IP handles multiple entities such as HDMI, Soundwire, local devices such as mics/speakers etc. The split for the core's functionality can be arbitrary or be defined by the DSP firmware topology and include hooks for test/debug. This allows for the audio core device to be minimal and tightly coupled with handling the hardware-specific logic and communication. The ancillary bus is intended to be minimal, generic and avoid domain-specific assumptions. Each ancillary bus device represents a part of its parent functionality. The generic behavior can be extended and specialized as needed by encapsulating an ancillary bus device within other domain-specific structures and the use of .ops callbacks. The SOF driver adopts the ancillary bus for implementing the multi-client support. A client in the context of the SOF driver represents a part of the core device's functionality. It is not a physical device but rather an ancillary device that needs to communicate with the DSP via IPCs. With multi-client support,the sound card can be separated into multiple orthogonal ancillary devices for local devices (mic/speakers etc), HDMI, sensing, probes, debug etc. In this series, we demonstrate the usage of the ancillary bus with the help of the IPC test client which is used for testing the serialization of IPCs when multiple clients talk to the DSP at the same time. v2 changes: defined pr_fmt for kernel messages replaced WARN_ON calls in registration with pr_err calls adding kernel-doc function comments for device_initialize and device_add fix typo in documentation removed inaccurate line in documentation fixed formatting in drivers/bus/Makefile changed unwind path for sof_client_dev_alloc() improved comments for client list and mem freeing during client unreg removed debugfs entries in sof_ipc_test_client_drv during remove changed the signature of sof_debug_ipc_flood_test() fix a looping error in ancillary_match_id updated error value in sof_client_dev_register() mutex held while traversing client list when unregistering clients updated includes in sof-client.h Dave Ertman (1): Add ancillary bus support Fred Oh (1): ASoC: SOF: debug: Remove IPC flood test support in SOF core Ranjani Sridharan (4): ASoC: SOF: Introduce descriptors for SOF client ASoC: SOF: Create client driver for IPC test ASoC: SOF: ops: Add ops for client registration ASoC: SOF: Intel: Define ops for client registration Documentation/driver-api/ancillary_bus.rst | 229 ++++++++++++++ Documentation/driver-api/index.rst | 1 + drivers/bus/Kconfig | 3 + drivers/bus/Makefile | 3 + drivers/bus/ancillary.c | 225 ++++++++++++++ include/linux/ancillary_bus.h | 69 +++++ include/linux/mod_devicetable.h | 8 + scripts/mod/devicetable-offsets.c | 3 + scripts/mod/file2alias.c | 8 + sound/soc/sof/Kconfig | 29 +- sound/soc/sof/Makefile | 7 + sound/soc/sof/core.c | 12 + sound/soc/sof/debug.c | 230 -------------- sound/soc/sof/intel/Kconfig | 9 + sound/soc/sof/intel/Makefile | 3 + sound/soc/sof/intel/apl.c | 18 ++ sound/soc/sof/intel/bdw.c | 18 ++ sound/soc/sof/intel/byt.c | 22 ++ sound/soc/sof/intel/cnl.c | 18 ++ sound/soc/sof/intel/intel-client.c | 53 ++++ sound/soc/sof/intel/intel-client.h | 26 ++ sound/soc/sof/ops.h | 14 + sound/soc/sof/sof-client.c | 119 ++++++++ sound/soc/sof/sof-client.h | 69 +++++ sound/soc/sof/sof-ipc-test-client.c | 332 +++++++++++++++++++++ sound/soc/sof/sof-priv.h | 19 +- 26 files changed, 1308 insertions(+), 239 deletions(-) create mode 100644 Documentation/driver-api/ancillary_bus.rst create mode 100644 drivers/bus/ancillary.c create mode 100644 include/linux/ancillary_bus.h create mode 100644 sound/soc/sof/intel/intel-client.c create mode 100644 sound/soc/sof/intel/intel-client.h create mode 100644 sound/soc/sof/sof-client.c create mode 100644 sound/soc/sof/sof-client.h create mode 100644 sound/soc/sof/sof-ipc-test-client.c -- 2.26.2

10 71

support the Roland UA-4FX2 card
by kalashnikov-HJ4JGG 13 Oct '20

13 Oct '20

Hello i am juan and i am trying to use this (Roland UA-4FX2) sound card on linux, I posted this on the github and they recommended to put it on this mailing list. from https://github.com/alsa-project/alsa-lib/issues/81 hi i'm trying to use this audio card with a Raspberry pi and y get this from the command dmesg on linux console ``` usb 3-2: new high-speed USB device number 6 using xhci_hcd usb 3-2: New USB device found, idVendor=0582, idProduct=01e2, bcdDevice= 0.2b usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-2: Product: UA-4FX2 usb 3-2: Manufacturer: ROLAND mc: Linux media interface: v0.10 usbcore: registered new interface driver snd-usb-audio usb 3-2: Unable to change format on ep #8e: already in use usb 3-2: Unable to change format on ep #8e: already in use : : ``` and when i try to select the device on a program get this ``` ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card ``` it seems that the card is not supported by ALSA lib. How is the procedure to add new cards to the driver? How can I help to do this? Thank you

1 0

[PATCH] ALSA: hda/hdmi: fix incorrect locking in hdmi_pcm_close
by Kai Vehmanen 13 Oct '20

13 Oct '20

A race exists between closing a PCM and update of ELD data. In hdmi_pcm_close(), hinfo->nid value is modified without taking spec->pcm_lock. If this happens concurrently while processing an ELD update in hdmi_pcm_setup_pin(), converter assignment may be done incorrectly. This bug was found by hitting a WARN_ON in snd_hda_spdif_ctls_assign() in a HDMI receiver connection stress test: [2739.684569] WARNING: CPU: 5 PID: 2090 at sound/pci/hda/patch_hdmi.c:1898 check_non_pcm_per_cvt+0x41/0x50 [snd_hda_codec_hdmi] ... [2739.684707] Call Trace: [2739.684720] update_eld+0x121/0x5a0 [snd_hda_codec_hdmi] [2739.684736] hdmi_present_sense+0x21e/0x3b0 [snd_hda_codec_hdmi] [2739.684750] check_presence_and_report+0x81/0xd0 [snd_hda_codec_hdmi] [2739.684842] intel_audio_codec_enable+0x122/0x190 [i915] Fixes: 42b2987079ec ("ALSA: hda - hdmi playback without monitor in dynamic pcm bind mode") Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/pci/hda/patch_hdmi.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 0ffbfcb91256..ccd1df059654 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2046,22 +2046,25 @@ static int hdmi_pcm_close(struct hda_pcm_stream *hinfo, int pinctl; int err = 0; + mutex_lock(&spec->pcm_lock); if (hinfo->nid) { pcm_idx = hinfo_to_pcm_index(codec, hinfo); - if (snd_BUG_ON(pcm_idx < 0)) - return -EINVAL; + if (snd_BUG_ON(pcm_idx < 0)) { + err = -EINVAL; + goto unlock; + } cvt_idx = cvt_nid_to_cvt_index(codec, hinfo->nid); - if (snd_BUG_ON(cvt_idx < 0)) - return -EINVAL; + if (snd_BUG_ON(cvt_idx < 0)) { + err = -EINVAL; + goto unlock; + } per_cvt = get_cvt(spec, cvt_idx); - snd_BUG_ON(!per_cvt->assigned); per_cvt->assigned = 0; hinfo->nid = 0; azx_stream(get_azx_dev(substream))->stripe = 0; - mutex_lock(&spec->pcm_lock); snd_hda_spdif_ctls_unassign(codec, pcm_idx); clear_bit(pcm_idx, &spec->pcm_in_use); pin_idx = hinfo_to_pin_index(codec, hinfo); @@ -2091,10 +2094,11 @@ static int hdmi_pcm_close(struct hda_pcm_stream *hinfo, per_pin->setup = false; per_pin->channels = 0; mutex_unlock(&per_pin->lock); - unlock: - mutex_unlock(&spec->pcm_lock); } +unlock: + mutex_unlock(&spec->pcm_lock); + return err; } -- 2.28.0

2 1

[PATCH] Asoc: qcom: lpass-cpu: Fix dp audio failure on monitors
by Srinivasa Rao Mandadapu 13 Oct '20

13 Oct '20

From: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Make LPASS_HDMI_TX_PARITY_ADDR reg as volatile to fix dp audio failure with external monitors. This patch is upgrade to below patch series. https://lore.kernel.org/patchwork/project/lkml/list/?series=466460 Signed-off-by: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Signed-off-by: Srinivasa Rao Mandadapu <srivasam(a)codeaurora.org> --- sound/soc/qcom/lpass-cpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c index ba2aca3..78de888 100644 --- a/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-cpu.c @@ -660,6 +660,8 @@ static bool lpass_hdmi_regmap_volatile(struct device *dev, unsigned int reg) return true; if (reg == LPASS_HDMI_TX_LEGACY_ADDR(v)) return true; + if (reg == LPASS_HDMI_TX_PARITY_ADDR(v)) + return true; for (i = 0; i < v->rdma_channels; ++i) { if (reg == LPAIF_HDMI_RDMACURR_REG(v, i)) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

1 0

[PATCH] ASoC: dmaengine: Document support for TX only or RX only streams
by Mark Brown 13 Oct '20

13 Oct '20

We intentionally do not return an error if we get a permanent failure from dma_request_chan() in order to support systems which have TX only or RX only channels. Add a comment documenting this. Reported-by: Andy Shevchenko <andriy.shevchenko(a)intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/soc-generic-dmaengine-pcm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c index fb95c1464e66..9ef80a48707e 100644 --- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -386,6 +386,11 @@ static int dmaengine_pcm_request_chan_of(struct dmaengine_pcm *pcm, name = config->chan_names[i]; chan = dma_request_chan(dev, name); if (IS_ERR(chan)) { + /* + * Only report probe deferral errors, channels + * might not be present for devices that + * support only TX or only RX. + */ if (PTR_ERR(chan) == -EPROBE_DEFER) return -EPROBE_DEFER; pcm->chan[i] = NULL; -- 2.20.1

2 9

[PATCH v3 0/2] DAI driver for new XCVR IP
by Viorel Suman (OSS) 13 Oct '20

13 Oct '20

From: Viorel Suman <viorel.suman(a)nxp.com> DAI driver for new XCVR IP found in i.MX8MP. Viorel Suman (2): ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver ASoC: dt-bindings: fsl_xcvr: Add document for XCVR Changes since v1: - improved 6- and 12-ch layout comment - used regmap polling function, improved clocks handling in runtime_resume - added FW size check in FW load function, improved IRQ handler, removed dummy IRQ handlers - fixed yaml file Changes since v2: - used devm_reset_control_get_exclusive instead of of_reset_control_get - moved reset_control_assert into runtime_suspend .../devicetree/bindings/sound/fsl,xcvr.yaml | 103 ++ sound/soc/fsl/Kconfig | 10 + sound/soc/fsl/Makefile | 2 + sound/soc/fsl/fsl_xcvr.c | 1356 ++++++++++++++++++++ sound/soc/fsl/fsl_xcvr.h | 266 ++++ 5 files changed, 1737 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,xcvr.yaml create mode 100644 sound/soc/fsl/fsl_xcvr.c create mode 100644 sound/soc/fsl/fsl_xcvr.h -- 2.7.4

2 4

[PATCH v6 56/80] dt-bindings: fix references to files converted to yaml
by Mauro Carvalho Chehab 13 Oct '20

13 Oct '20

There were several files converted to yaml, but the .txt file is still referenced somewhere else. Update the references for them to point to the right file. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- .../bindings/display/tilcdc/tilcdc.txt | 2 +- .../devicetree/bindings/mailbox/omap-mailbox.txt | 2 +- .../devicetree/bindings/media/i2c/tvp5150.txt | 2 +- .../bindings/pwm/google,cros-ec-pwm.yaml | 2 +- .../bindings/soc/qcom/qcom,smd-rpm.yaml | 2 +- .../bindings/sound/google,cros-ec-codec.yaml | 2 +- MAINTAINERS | 16 ++++++++-------- 7 files changed, 14 insertions(+), 14 deletions(-) diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt index 8b2a71395647..3e64075ac7ec 100644 --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt @@ -37,7 +37,7 @@ Optional nodes: supports a single port with a single endpoint. - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and - Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt for connecting + Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml for connecting tfp410 DVI encoder or lcd panel to lcdc [1] There is an errata about AM335x color wiring. For 16-bit color mode diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt index 35c3f56b7f7b..5fe80c1c19fc 100644 --- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt +++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt @@ -69,7 +69,7 @@ The following are mandatory properties for the K3 AM65x and J721E SoCs only: the interrupt routes between the IP and the main GIC controllers. See the following binding for additional details, - Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt + Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml Child Nodes: ============ diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt index 6c88ce858d08..719b2995dc17 100644 --- a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt +++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt @@ -56,7 +56,7 @@ Optional Connector Properties: instead of using the autodetection mechnism. Please look at [1] for more information. -[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt. +[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml. Example - three input sources: #include <dt-bindings/display/sdtv-standards.h> diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml index 41ece1d85315..4cfbffd8414a 100644 --- a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml @@ -14,7 +14,7 @@ description: | Google's ChromeOS EC PWM is a simple PWM attached to the Embedded Controller (EC) and controlled via a host-command interface. An EC PWM node should be only found as a sub-node of the EC node (see - Documentation/devicetree/bindings/mfd/cros-ec.txt). + Documentation/devicetree/bindings/mfd/google,cros-ec.yaml). properties: compatible: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index 468d658ce3e7..2684f22a1d85 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -20,7 +20,7 @@ description: | present and this subnode may contain children that designate regulator resources. - Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt + Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml for information on the regulator subnodes that can exist under the rpm_requests. diff --git a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml index c84e656afb0a..3b9143af2c7c 100644 --- a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml +++ b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml @@ -13,7 +13,7 @@ description: | Google's ChromeOS EC codec is a digital mic codec provided by the Embedded Controller (EC) and is controlled via a host-command interface. An EC codec node should only be found as a sub-node of the EC node (see - Documentation/devicetree/bindings/mfd/cros-ec.txt). + Documentation/devicetree/bindings/mfd/google,cros-ec.yaml). properties: compatible: diff --git a/MAINTAINERS b/MAINTAINERS index dffa948a2124..9e0f7b68bba5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1523,7 +1523,7 @@ L: linux-arm-kernel(a)lists.infradead.org (moderated for non-subscribers) S: Maintained F: Documentation/devicetree/bindings/arm/actions.yaml F: Documentation/devicetree/bindings/clock/actions,owl-cmu.txt -F: Documentation/devicetree/bindings/dma/owl-dma.txt +F: Documentation/devicetree/bindings/dma/owl-dma.yaml F: Documentation/devicetree/bindings/i2c/i2c-owl.txt F: Documentation/devicetree/bindings/mmc/owl-mmc.yaml F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt @@ -5827,7 +5827,7 @@ L: linux-renesas-soc(a)vger.kernel.org S: Supported T: git git://linuxtv.org/pinchartl/media drm/du/next F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt -F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt +F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml F: Documentation/devicetree/bindings/display/renesas,du.txt F: drivers/gpu/drm/rcar-du/ F: drivers/gpu/drm/shmobile/ @@ -6952,7 +6952,7 @@ M: Frank Li <Frank.li(a)nxp.com> L: linux-arm-kernel(a)lists.infradead.org S: Maintained F: Documentation/admin-guide/perf/imx-ddr.rst -F: Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt +F: Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml F: drivers/perf/fsl_imx8_ddr_perf.c FREESCALE IMX I2C DRIVER @@ -6960,7 +6960,7 @@ M: Oleksij Rempel <o.rempel(a)pengutronix.de> R: Pengutronix Kernel Team <kernel(a)pengutronix.de> L: linux-i2c(a)vger.kernel.org S: Maintained -F: Documentation/devicetree/bindings/i2c/i2c-imx.txt +F: Documentation/devicetree/bindings/i2c/i2c-imx.yaml F: drivers/i2c/busses/i2c-imx.c FREESCALE IMX LPI2C DRIVER @@ -6968,7 +6968,7 @@ M: Dong Aisheng <aisheng.dong(a)nxp.com> L: linux-i2c(a)vger.kernel.org L: linux-imx(a)nxp.com S: Maintained -F: Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt +F: Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml F: drivers/i2c/busses/i2c-imx-lpi2c.c FREESCALE QORIQ DPAA ETHERNET DRIVER @@ -11600,7 +11600,7 @@ MIPS GENERIC PLATFORM M: Paul Burton <paulburton(a)kernel.org> L: linux-mips(a)vger.kernel.org S: Supported -F: Documentation/devicetree/bindings/power/mti,mips-cpc.txt +F: Documentation/devicetree/bindings/power/mti,mips-cpc.yaml F: arch/mips/generic/ F: arch/mips/tools/generic-board-config.sh @@ -12455,7 +12455,7 @@ NXP SGTL5000 DRIVER M: Fabio Estevam <festevam(a)gmail.com> L: alsa-devel(a)alsa-project.org (moderated for non-subscribers) S: Maintained -F: Documentation/devicetree/bindings/sound/sgtl5000.txt +F: Documentation/devicetree/bindings/sound/sgtl5000.yaml F: sound/soc/codecs/sgtl5000* NXP SJA1105 ETHERNET SWITCH DRIVER @@ -16737,7 +16737,7 @@ SYNOPSYS DESIGNWARE DMAC DRIVER M: Viresh Kumar <vireshk(a)kernel.org> R: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> S: Maintained -F: Documentation/devicetree/bindings/dma/snps-dma.txt +F: Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml F: drivers/dma/dw/ F: include/dt-bindings/dma/dw-dmac.h F: include/linux/dma/dw.h -- 2.26.2

1 0

[PATCH v6 39/80] docs: writing-an-alsa-driver.rst: fix some bad c:func: markups
by Mauro Carvalho Chehab 13 Oct '20

13 Oct '20

Some such markups are invalid, as reported by Sphinx: ./Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3317: WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*' Invalid C declaration: Expected end of definition. [error at 20] snd_rawmidi_transmit* --------------------^ ./Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3917: WARNING: Unparseable C cross-reference: 'copy_from/to_user' Invalid C declaration: Expected end of definition. [error at 9] copy_from/to_user ---------^ The first case seems to be better replaced by a literal. For the second one, let's generate cross-references, by spliting it in two. Reviewed-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 85d6e9c643ef..73bbd59afc33 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -3315,8 +3315,7 @@ data and removes them from the buffer at once: } If you know beforehand how many bytes you can accept, you can use a -buffer size greater than one with the -:c:func:`snd_rawmidi_transmit\*()` functions. +buffer size greater than one with the ``snd_rawmidi_transmit*()`` functions. The ``trigger`` callback must not sleep. If the hardware FIFO is full before the substream buffer has been emptied, you have to continue @@ -3916,7 +3915,7 @@ the maximum size of the proc file access. The read/write callbacks of raw mode are more direct than the text mode. You need to use a low-level I/O functions such as -:c:func:`copy_from/to_user()` to transfer the data. +:c:func:`copy_from_user()` and :c:func:`copy_to_user()` to transfer the data. :: -- 2.26.2

1 0

[PATCH v6 37/80] docs: sound: writing-an-alsa-driver.rst: get rid of :c:type
by Mauro Carvalho Chehab 13 Oct '20

13 Oct '20

the :c:type shouldn't be used with structs with Sphinx 3, as the C domain there uses .. c:struct for structs. As we have the automarkup extension, let's just get rid of all :c:type as a whole, as those will be automagically marked as such. This solves a bunch of warnings with Sphinx 3, like those: .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:490: WARNING: Unparseable C cross-reference: 'calling snd_card_free' Invalid C declaration: Expected end of definition. [error at 8] calling snd_card_free --------^ .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3328: WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*' Invalid C declaration: Expected end of definition. [error at 20] snd_rawmidi_transmit* --------------------^ .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3928: WARNING: Unparseable C cross-reference: 'copy_from/to_user' Invalid C declaration: Expected end of definition. [error at 9] copy_from/to_user ---------^ Reviewed-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- .../kernel-api/writing-an-alsa-driver.rst | 105 ++++++++---------- 1 file changed, 47 insertions(+), 58 deletions(-) diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index aa9d5ab183d2..85d6e9c643ef 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -194,7 +194,7 @@ The minimum flow for PCI soundcards is as follows: - create ``remove`` callback. -- create a :c:type:`struct pci_driver <pci_driver>` structure +- create a struct pci_driver structure containing the three pointers above. - create an ``init`` function just calling the @@ -487,7 +487,7 @@ The destructor, remove callback, simply releases the card instance. Then the ALSA middle layer will release all the attached components automatically. -It would be typically just :c:func:`calling snd_card_free()`: +It would be typically just calling :c:func:`snd_card_free()`: :: @@ -560,16 +560,15 @@ return the card instance. The extra_size argument is used to allocate card->private_data for the chip-specific data. Note that these data are allocated by :c:func:`snd_card_new()`. -The first argument, the pointer of struct :c:type:`struct device -<device>`, specifies the parent device. For PCI devices, typically -``&pci->`` is passed there. +The first argument, the pointer of struct device, specifies the parent +device. For PCI devices, typically ``&pci->`` is passed there. Components ---------- After the card is created, you can attach the components (devices) to the card instance. In an ALSA driver, a component is represented as a -:c:type:`struct snd_device <snd_device>` object. A component +struct snd_device object. A component can be a PCM instance, a control interface, a raw MIDI interface, etc. Each such instance has one component entry. @@ -628,7 +627,7 @@ argument of :c:func:`snd_card_new()`, i.e. err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, sizeof(struct mychip), &card); -:c:type:`struct mychip <mychip>` is the type of the chip record. +struct mychip is the type of the chip record. In return, the allocated record can be accessed as @@ -890,7 +889,7 @@ functions. These resources must be released in the destructor function (see below). Now assume that the PCI device has an I/O port with 8 bytes and an -interrupt. Then :c:type:`struct mychip <mychip>` will have the +interrupt. Then struct mychip will have the following fields: :: @@ -1094,7 +1093,7 @@ PCI Entries ----------- So far, so good. Let's finish the missing PCI stuff. At first, we need a -:c:type:`struct pci_device_id <pci_device_id>` table for +struct pci_device_id table for this chipset. It's a table of PCI vendor/device ID number, and some masks. @@ -1110,19 +1109,17 @@ For example, }; MODULE_DEVICE_TABLE(pci, snd_mychip_ids); -The first and second fields of the :c:type:`struct pci_device_id -<pci_device_id>` structure are the vendor and device IDs. If you -have no reason to filter the matching devices, you can leave the -remaining fields as above. The last field of the :c:type:`struct -pci_device_id <pci_device_id>` struct contains private data -for this entry. You can specify any value here, for example, to define -specific operations for supported device IDs. Such an example is found -in the intel8x0 driver. +The first and second fields of the struct pci_device_id are the vendor +and device IDs. If you have no reason to filter the matching devices, you can +leave the remaining fields as above. The last field of the +struct pci_device_id contains private data for this entry. You can specify +any value here, for example, to define specific operations for supported +device IDs. Such an example is found in the intel8x0 driver. The last entry of this list is the terminator. You must specify this all-zero entry. -Then, prepare the :c:type:`struct pci_driver <pci_driver>` +Then, prepare the struct pci_driver record: :: @@ -1439,8 +1436,8 @@ corresponding argument. If a chip supports multiple playbacks or captures, you can specify more numbers, but they must be handled properly in open/close, etc. callbacks. When you need to know which substream you are referring to, -then it can be obtained from :c:type:`struct snd_pcm_substream -<snd_pcm_substream>` data passed to each callback as follows: +then it can be obtained from struct snd_pcm_substream data passed to each +callback as follows: :: @@ -1639,10 +1636,9 @@ In the sections below, important records are explained. Hardware Description ~~~~~~~~~~~~~~~~~~~~ -The hardware descriptor (:c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>`) contains the definitions of the fundamental -hardware configuration. Above all, you'll need to define this in the -`PCM open callback`_. Note that the runtime instance holds the copy of +The hardware descriptor (struct snd_pcm_hardware) contains the definitions of +the fundamental hardware configuration. Above all, you'll need to define this +in the `PCM open callback`_. Note that the runtime instance holds the copy of the descriptor, not the pointer to the existing descriptor. That is, in the open callback, you can modify the copied descriptor (``runtime->hw``) as you need. For example, if the maximum number of @@ -1800,14 +1796,13 @@ Running Status ~~~~~~~~~~~~~~ The running status can be referred via ``runtime->status``. This is -the pointer to the :c:type:`struct snd_pcm_mmap_status -<snd_pcm_mmap_status>` record. For example, you can get the current +the pointer to the struct snd_pcm_mmap_status record. +For example, you can get the current DMA hardware pointer via ``runtime->status->hw_ptr``. The DMA application pointer can be referred via ``runtime->control``, -which points to the :c:type:`struct snd_pcm_mmap_control -<snd_pcm_mmap_control>` record. However, accessing directly to -this value is not recommended. +which points to the struct snd_pcm_mmap_control record. +However, accessing directly to this value is not recommended. Private Data ~~~~~~~~~~~~ @@ -1843,8 +1838,8 @@ error number such as ``-EINVAL``. To choose an appropriate error number, it is advised to check what value other parts of the kernel return when the same kind of request fails. -The callback function takes at least the argument with :c:type:`struct -snd_pcm_substream <snd_pcm_substream>` pointer. To retrieve the chip +The callback function takes at least the argument with +struct snd_pcm_substream pointer. To retrieve the chip record from the given substream instance, you can use the following macro. @@ -2313,10 +2308,10 @@ non-atomic contexts. For example, the function :c:func:`snd_pcm_period_elapsed()` is called typically from the interrupt handler. But, if you set up the driver to use a threaded interrupt handler, this call can be in non-atomic context, too. In such -a case, you can set ``nonatomic`` filed of :c:type:`struct snd_pcm -<snd_pcm>` object after creating it. When this flag is set, mutex -and rwsem are used internally in the PCM core instead of spin and -rwlocks, so that you can call all PCM functions safely in a non-atomic +a case, you can set ``nonatomic`` filed of struct snd_pcm object +after creating it. When this flag is set, mutex and rwsem are used internally +in the PCM core instead of spin and rwlocks, so that you can call all PCM +functions safely in a non-atomic context. Constraints @@ -2357,8 +2352,7 @@ There are many different constraints. Look at ``sound/pcm.h`` for a complete list. You can even define your own constraint rules. For example, let's suppose my_chip can manage a substream of 1 channel if and only if the format is ``S16_LE``, otherwise it supports any format -specified in the :c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>` structure (or in any other +specified in struct snd_pcm_hardware> (or in any other constraint_list). You can build a rule like this: :: @@ -2467,7 +2461,7 @@ Definition of Controls To create a new control, you need to define the following three callbacks: ``info``, ``get`` and ``put``. Then, define a -:c:type:`struct snd_kcontrol_new <snd_kcontrol_new>` record, such as: +struct snd_kcontrol_new record, such as: :: @@ -2602,8 +2596,8 @@ info callback ~~~~~~~~~~~~~ The ``info`` callback is used to get detailed information on this -control. This must store the values of the given :c:type:`struct -snd_ctl_elem_info <snd_ctl_elem_info>` object. For example, +control. This must store the values of the given +struct snd_ctl_elem_info object. For example, for a boolean control with a single element: :: @@ -2774,13 +2768,11 @@ In the simplest way, you can do like this: if (err < 0) return err; -where ``my_control`` is the :c:type:`struct snd_kcontrol_new -<snd_kcontrol_new>` object defined above, and chip is the object -pointer to be passed to kcontrol->private_data which can be referred -to in callbacks. +where ``my_control`` is the struct snd_kcontrol_new object defined above, +and chip is the object pointer to be passed to kcontrol->private_data which +can be referred to in callbacks. -:c:func:`snd_ctl_new1()` allocates a new :c:type:`struct -snd_kcontrol <snd_kcontrol>` instance, and +:c:func:`snd_ctl_new1()` allocates a new struct snd_kcontrol instance, and :c:func:`snd_ctl_add()` assigns the given control component to the card. @@ -2797,10 +2789,9 @@ can call :c:func:`snd_ctl_notify()`. For example, This function takes the card pointer, the event-mask, and the control id pointer for the notification. The event-mask specifies the types of notification, for example, in the above example, the change of control -values is notified. The id pointer is the pointer of :c:type:`struct -snd_ctl_elem_id <snd_ctl_elem_id>` to be notified. You can -find some examples in ``es1938.c`` or ``es1968.c`` for hardware volume -interrupts. +values is notified. The id pointer is the pointer of struct snd_ctl_elem_id +to be notified. You can find some examples in ``es1938.c`` or ``es1968.c`` +for hardware volume interrupts. Metadata -------- @@ -2915,9 +2906,8 @@ with an ``ac97_bus_ops_t`` record with callback functions. The bus record is shared among all belonging ac97 instances. -And then call :c:func:`snd_ac97_mixer()` with an :c:type:`struct -snd_ac97_template <snd_ac97_template>` record together with -the bus pointer created above. +And then call :c:func:`snd_ac97_mixer()` with an struct snd_ac97_template +record together with the bus pointer created above. :: @@ -3118,11 +3108,10 @@ devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see Usually, the port address corresponds to the command port and port + 1 corresponds to the data port. If not, you may change the ``cport`` -field of :c:type:`struct snd_mpu401 <snd_mpu401>` manually afterward. -However, :c:type:`struct snd_mpu401 <snd_mpu401>` pointer is +field of struct snd_mpu401 manually afterward. +However, struct snd_mpu401 pointer is not returned explicitly by :c:func:`snd_mpu401_uart_new()`. You -need to cast ``rmidi->private_data`` to :c:type:`struct snd_mpu401 -<snd_mpu401>` explicitly, +need to cast ``rmidi->private_data`` to struct snd_mpu401 explicitly, :: @@ -3772,7 +3761,7 @@ For creating the SG-buffer handler, call :c:func:`snd_pcm_set_managed_buffer_all()` with ``SNDRV_DMA_TYPE_DEV_SG`` in the PCM constructor like other PCI pre-allocator. You need to pass ``&pci->dev``, where pci is -the :c:type:`struct pci_dev <pci_dev>` pointer of the chip as +the struct pci_dev pointer of the chip as well. :: -- 2.26.2

1 0

[PATCH v6 29/80] docs: remove sound API duplication
by Mauro Carvalho Chehab 13 Oct '20

13 Oct '20

The sound API is documented on two different parts: under Documentation/driver-api/sound.rst and under Documentation/sound/kernel-api/alsa-driver-api.rst. The alsa-driver-api.rst seems more complete, and APIs are split per type. There's just one missing kernel-doc markup there. Add it and drop the duplicated one. Reviewed-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- Documentation/driver-api/index.rst | 1 - Documentation/driver-api/sound.rst | 54 ------------------- .../sound/kernel-api/alsa-driver-api.rst | 1 + 3 files changed, 1 insertion(+), 55 deletions(-) delete mode 100644 Documentation/driver-api/sound.rst diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 5ef2cfe3a16b..90d02c5fb155 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -28,7 +28,6 @@ available subsections can be seen below. component message-based infiniband - sound frame-buffer regulator iio/index diff --git a/Documentation/driver-api/sound.rst b/Documentation/driver-api/sound.rst deleted file mode 100644 index afef6eabc073..000000000000 --- a/Documentation/driver-api/sound.rst +++ /dev/null @@ -1,54 +0,0 @@ -Sound Devices -============= - -.. kernel-doc:: include/sound/core.h - :internal: - -.. kernel-doc:: sound/sound_core.c - :export: - -.. kernel-doc:: include/sound/pcm.h - :internal: - -.. kernel-doc:: sound/core/pcm.c - :export: - -.. kernel-doc:: sound/core/device.c - :export: - -.. kernel-doc:: sound/core/info.c - :export: - -.. kernel-doc:: sound/core/rawmidi.c - :export: - -.. kernel-doc:: sound/core/sound.c - :export: - -.. kernel-doc:: sound/core/memory.c - :export: - -.. kernel-doc:: sound/core/pcm_memory.c - :export: - -.. kernel-doc:: sound/core/init.c - :export: - -.. kernel-doc:: sound/core/isadma.c - :export: - -.. kernel-doc:: sound/core/control.c - :export: - -.. kernel-doc:: sound/core/pcm_lib.c - :export: - -.. kernel-doc:: sound/core/hwdep.c - :export: - -.. kernel-doc:: sound/core/pcm_native.c - :export: - -.. kernel-doc:: sound/core/memalloc.c - :export: - diff --git a/Documentation/sound/kernel-api/alsa-driver-api.rst b/Documentation/sound/kernel-api/alsa-driver-api.rst index c8cc651eccf7..d24c64df7069 100644 --- a/Documentation/sound/kernel-api/alsa-driver-api.rst +++ b/Documentation/sound/kernel-api/alsa-driver-api.rst @@ -132,3 +132,4 @@ ISA DMA Helpers Other Helper Macros ------------------- .. kernel-doc:: include/sound/core.h +.. kernel-doc:: sound/sound_core.c -- 2.26.2

1 0

[PATCH v6 23/80] docs: get rid of :c:type explicit declarations for structs
by Mauro Carvalho Chehab 13 Oct '20

13 Oct '20

The :c:type:`foo` only works properly with structs before Sphinx 3.x. On Sphinx 3.x, structs should now be declared using the .. c:struct, and referenced via :c:struct tag. As we now have the automarkup.py macro, that automatically convert: struct foo into cross-references, let's get rid of that, solving several warnings when building docs with Sphinx 3.x. Reviewed-by: André Almeida <andrealmeid(a)collabora.com> # blk-mq.rst Reviewed-by: Takashi Iwai <tiwai(a)suse.de> # sound Reviewed-by: Mike Rapoport <rppt(a)linux.ibm.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- Documentation/block/blk-mq.rst | 8 +++---- Documentation/block/inline-encryption.rst | 8 +++---- Documentation/driver-api/fpga/fpga-bridge.rst | 4 ++-- Documentation/driver-api/fpga/fpga-mgr.rst | 4 ++-- Documentation/driver-api/fpga/fpga-region.rst | 2 +- Documentation/driver-api/iio/buffers.rst | 2 +- Documentation/driver-api/iio/core.rst | 6 ++--- Documentation/driver-api/iio/hw-consumer.rst | 2 +- .../driver-api/iio/triggered-buffers.rst | 2 +- Documentation/driver-api/iio/triggers.rst | 4 ++-- .../driver-api/media/dtv-frontend.rst | 4 ++-- Documentation/driver-api/media/mc-core.rst | 24 +++++++++---------- .../driver-api/media/v4l2-controls.rst | 2 +- Documentation/driver-api/media/v4l2-dev.rst | 8 +++---- .../driver-api/media/v4l2-device.rst | 6 ++--- Documentation/driver-api/media/v4l2-event.rst | 10 ++++---- Documentation/driver-api/media/v4l2-fh.rst | 16 ++++++------- .../driver-api/media/v4l2-subdev.rst | 2 +- Documentation/driver-api/regulator.rst | 4 ++-- Documentation/driver-api/usb/URB.rst | 2 +- Documentation/driver-api/usb/gadget.rst | 10 ++++---- Documentation/driver-api/usb/hotplug.rst | 2 +- Documentation/filesystems/fscrypt.rst | 14 +++++------ Documentation/filesystems/fsverity.rst | 2 +- Documentation/sound/designs/tracepoints.rst | 22 ++++++++--------- Documentation/sphinx/parse-headers.pl | 2 +- Documentation/vm/ksm.rst | 2 +- Documentation/vm/memory-model.rst | 6 ++--- mm/ksm.c | 2 +- mm/memblock.c | 4 ++-- 30 files changed, 93 insertions(+), 93 deletions(-) diff --git a/Documentation/block/blk-mq.rst b/Documentation/block/blk-mq.rst index 88c56afcb070..86a632af02b0 100644 --- a/Documentation/block/blk-mq.rst +++ b/Documentation/block/blk-mq.rst @@ -63,10 +63,10 @@ Software staging queues ~~~~~~~~~~~~~~~~~~~~~~~ The block IO subsystem adds requests in the software staging queues -(represented by struct :c:type:`blk_mq_ctx`) in case that they weren't sent +(represented by struct blk_mq_ctx) in case that they weren't sent directly to the driver. A request is one or more BIOs. They arrived at the -block layer through the data structure struct :c:type:`bio`. The block layer -will then build a new structure from it, the struct :c:type:`request` that will +block layer through the data structure struct bio. The block layer +will then build a new structure from it, the struct request that will be used to communicate with the device driver. Each queue has its own lock and the number of queues is defined by a per-CPU or per-node basis. @@ -102,7 +102,7 @@ hardware queue will be drained in sequence according to their mapping. Hardware dispatch queues ~~~~~~~~~~~~~~~~~~~~~~~~ -The hardware queue (represented by struct :c:type:`blk_mq_hw_ctx`) is a struct +The hardware queue (represented by struct blk_mq_hw_ctx) is a struct used by device drivers to map the device submission queues (or device DMA ring buffer), and are the last step of the block layer submission code before the low level device driver taking ownership of the request. To run this queue, the diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 354817b80887..e75151e467d3 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -52,7 +52,7 @@ Constraints and notes Design ====== -We add a :c:type:`struct bio_crypt_ctx` to :c:type:`struct bio` that can +We add a struct bio_crypt_ctx to struct bio that can represent an encryption context, because we need to be able to pass this encryption context from the upper layers (like the fs layer) to the device driver to act upon. @@ -85,7 +85,7 @@ blk-mq changes, other block layer changes and blk-crypto-fallback ================================================================= We add a pointer to a ``bi_crypt_context`` and ``keyslot`` to -:c:type:`struct request`. These will be referred to as the ``crypto fields`` +struct request. These will be referred to as the ``crypto fields`` for the request. This ``keyslot`` is the keyslot into which the ``bi_crypt_context`` has been programmed in the KSM of the ``request_queue`` that this request is being sent to. @@ -118,7 +118,7 @@ of the algorithm being used adheres to spec and functions correctly). If a ``request queue``'s inline encryption hardware claimed to support the encryption context specified with a bio, then it will not be handled by the ``blk-crypto-fallback``. We will eventually reach a point in blk-mq when a -:c:type:`struct request` needs to be allocated for that bio. At that point, +struct request needs to be allocated for that bio. At that point, blk-mq tries to program the encryption context into the ``request_queue``'s keyslot_manager, and obtain a keyslot, which it stores in its newly added ``keyslot`` field. This keyslot is released when the request is completed. @@ -188,7 +188,7 @@ keyslots supported by the hardware. The device driver also needs to tell the KSM how to actually manipulate the IE hardware in the device to do things like programming the crypto key into the IE hardware into a particular keyslot. All this is achieved through the -:c:type:`struct blk_ksm_ll_ops` field in the KSM that the device driver +struct blk_ksm_ll_ops field in the KSM that the device driver must fill up after initing the ``blk_keyslot_manager``. The KSM also handles runtime power management for the device when applicable diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst index ccd677ba7d76..198aadafd3e7 100644 --- a/Documentation/driver-api/fpga/fpga-bridge.rst +++ b/Documentation/driver-api/fpga/fpga-bridge.rst @@ -4,8 +4,8 @@ FPGA Bridge API to implement a new FPGA bridge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* struct :c:type:`fpga_bridge` — The FPGA Bridge structure -* struct :c:type:`fpga_bridge_ops` — Low level Bridge driver ops +* struct fpga_bridge — The FPGA Bridge structure +* struct fpga_bridge_ops — Low level Bridge driver ops * devm_fpga_bridge_create() — Allocate and init a bridge struct * fpga_bridge_register() — Register a bridge * fpga_bridge_unregister() — Unregister a bridge diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst index af5382af1379..22f7885b32c9 100644 --- a/Documentation/driver-api/fpga/fpga-mgr.rst +++ b/Documentation/driver-api/fpga/fpga-mgr.rst @@ -102,8 +102,8 @@ API for implementing a new FPGA Manager driver ---------------------------------------------- * ``fpga_mgr_states`` — Values for :c:member:`fpga_manager->state`. -* struct :c:type:`fpga_manager` — the FPGA manager struct -* struct :c:type:`fpga_manager_ops` — Low level FPGA manager driver ops +* struct fpga_manager — the FPGA manager struct +* struct fpga_manager_ops — Low level FPGA manager driver ops * devm_fpga_mgr_create() — Allocate and init a manager struct * fpga_mgr_register() — Register an FPGA manager * fpga_mgr_unregister() — Unregister an FPGA manager diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst index 31118a8ba218..3e52be7e2968 100644 --- a/Documentation/driver-api/fpga/fpga-region.rst +++ b/Documentation/driver-api/fpga/fpga-region.rst @@ -45,7 +45,7 @@ An example of usage can be seen in the probe function of [#f2]_. API to add a new FPGA region ---------------------------- -* struct :c:type:`fpga_region` — The FPGA region struct +* struct fpga_region — The FPGA region struct * devm_fpga_region_create() — Allocate and init a region struct * fpga_region_register() — Register an FPGA region * fpga_region_unregister() — Unregister an FPGA region diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst index dd64c9c5fb1e..3ddebddc02ca 100644 --- a/Documentation/driver-api/iio/buffers.rst +++ b/Documentation/driver-api/iio/buffers.rst @@ -2,7 +2,7 @@ Buffers ======= -* struct :c:type:`iio_buffer` — general buffer structure +* struct iio_buffer — general buffer structure * :c:func:`iio_validate_scan_mask_onehot` — Validates that exactly one channel is selected * :c:func:`iio_buffer_get` — Grab a reference to the buffer diff --git a/Documentation/driver-api/iio/core.rst b/Documentation/driver-api/iio/core.rst index 51b21e002396..715cf29482a1 100644 --- a/Documentation/driver-api/iio/core.rst +++ b/Documentation/driver-api/iio/core.rst @@ -10,7 +10,7 @@ applications manipulating sensors. The implementation can be found under Industrial I/O Devices ---------------------- -* struct :c:type:`iio_dev` - industrial I/O device +* struct iio_dev - industrial I/O device * iio_device_alloc() - allocate an :c:type:`iio_dev` from a driver * iio_device_free() - free an :c:type:`iio_dev` from a driver * iio_device_register() - register a device with the IIO subsystem @@ -66,7 +66,7 @@ Common attributes are: IIO device channels =================== -struct :c:type:`iio_chan_spec` - specification of a single channel +struct iio_chan_spec - specification of a single channel An IIO device channel is a representation of a data channel. An IIO device can have one or multiple channels. For example: @@ -77,7 +77,7 @@ have one or multiple channels. For example: * an accelerometer can have up to 3 channels representing acceleration on X, Y and Z axes. -An IIO channel is described by the struct :c:type:`iio_chan_spec`. +An IIO channel is described by the struct iio_chan_spec. A thermometer driver for the temperature sensor in the example above would have to describe its channel as follows:: diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst index 819fb9edc005..76133a3796f2 100644 --- a/Documentation/driver-api/iio/hw-consumer.rst +++ b/Documentation/driver-api/iio/hw-consumer.rst @@ -8,7 +8,7 @@ software buffer for data. The implementation can be found under :file:`drivers/iio/buffer/hw-consumer.c` -* struct :c:type:`iio_hw_consumer` — Hardware consumer structure +* struct iio_hw_consumer — Hardware consumer structure * :c:func:`iio_hw_consumer_alloc` — Allocate IIO hardware consumer * :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer * :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst index 0db12660cc90..417555dbbdf4 100644 --- a/Documentation/driver-api/iio/triggered-buffers.rst +++ b/Documentation/driver-api/iio/triggered-buffers.rst @@ -10,7 +10,7 @@ IIO triggered buffer setup * :c:func:`iio_triggered_buffer_setup` — Setup triggered buffer and pollfunc * :c:func:`iio_triggered_buffer_cleanup` — Free resources allocated by :c:func:`iio_triggered_buffer_setup` -* struct :c:type:`iio_buffer_setup_ops` — buffer setup related callbacks +* struct iio_buffer_setup_ops — buffer setup related callbacks A typical triggered buffer setup looks like this:: diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst index dfd7ba3eabde..288625e40672 100644 --- a/Documentation/driver-api/iio/triggers.rst +++ b/Documentation/driver-api/iio/triggers.rst @@ -2,7 +2,7 @@ Triggers ======== -* struct :c:type:`iio_trigger` — industrial I/O trigger device +* struct iio_trigger — industrial I/O trigger device * :c:func:`devm_iio_trigger_alloc` — Resource-managed iio_trigger_alloc * :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register iio_trigger_unregister @@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver:: IIO trigger ops =============== -* struct :c:type:`iio_trigger_ops` — operations structure for an iio_trigger. +* struct iio_trigger_ops — operations structure for an iio_trigger. Notice that a trigger has a set of operations attached: diff --git a/Documentation/driver-api/media/dtv-frontend.rst b/Documentation/driver-api/media/dtv-frontend.rst index b362109bb131..91f77fe58e83 100644 --- a/Documentation/driver-api/media/dtv-frontend.rst +++ b/Documentation/driver-api/media/dtv-frontend.rst @@ -125,7 +125,7 @@ responsible for tuning the device. It supports multiple algorithms to detect a channel, as defined at enum :c:func:`dvbfe_algo`. The algorithm to be used is obtained via ``.get_frontend_algo``. If the driver -doesn't fill its field at struct :c:type:`dvb_frontend_ops`, it will default to +doesn't fill its field at struct dvb_frontend_ops, it will default to ``DVBFE_ALGO_SW``, meaning that the dvb-core will do a zigzag when tuning, e. g. it will try first to use the specified center frequency ``f``, then, it will do ``f`` + |delta|, ``f`` - |delta|, ``f`` + 2 x |delta|, @@ -140,7 +140,7 @@ define a ``.get_frontend_algo`` function that would return ``DVBFE_ALGO_HW``. a third type (``DVBFE_ALGO_CUSTOM``), in order to allow the driver to define its own hardware-assisted algorithm. Very few hardware need to use it nowadays. Using ``DVBFE_ALGO_CUSTOM`` require to provide other - function callbacks at struct :c:type:`dvb_frontend_ops`. + function callbacks at struct dvb_frontend_ops. Attaching frontend driver to the bridge driver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/driver-api/media/mc-core.rst b/Documentation/driver-api/media/mc-core.rst index 05bba0b61748..57b5bbba944e 100644 --- a/Documentation/driver-api/media/mc-core.rst +++ b/Documentation/driver-api/media/mc-core.rst @@ -36,7 +36,7 @@ pad to a sink pad. Media device ^^^^^^^^^^^^ -A media device is represented by a struct :c:type:`media_device` +A media device is represented by a struct media_device instance, defined in ``include/media/media-device.h``. Allocation of the structure is handled by the media device driver, usually by embedding the :c:type:`media_device` instance in a larger driver-specific @@ -49,7 +49,7 @@ and unregistered by calling :c:func:`media_device_unregister()`. Entities ^^^^^^^^ -Entities are represented by a struct :c:type:`media_entity` +Entities are represented by a struct media_entity instance, defined in ``include/media/media-entity.h``. The structure is usually embedded into a higher-level structure, such as :c:type:`v4l2_subdev` or :c:type:`video_device` @@ -67,10 +67,10 @@ Interfaces ^^^^^^^^^^ Interfaces are represented by a -struct :c:type:`media_interface` instance, defined in +struct media_interface instance, defined in ``include/media/media-entity.h``. Currently, only one type of interface is defined: a device node. Such interfaces are represented by a -struct :c:type:`media_intf_devnode`. +struct media_intf_devnode. Drivers initialize and create device node interfaces by calling :c:func:`media_devnode_create()` @@ -79,7 +79,7 @@ and remove them by calling: Pads ^^^^ -Pads are represented by a struct :c:type:`media_pad` instance, +Pads are represented by a struct media_pad instance, defined in ``include/media/media-entity.h``. Each entity stores its pads in a pads array managed by the entity driver. Drivers usually embed the array in a driver-specific structure. @@ -87,8 +87,8 @@ a driver-specific structure. Pads are identified by their entity and their 0-based index in the pads array. -Both information are stored in the struct :c:type:`media_pad`, -making the struct :c:type:`media_pad` pointer the canonical way +Both information are stored in the struct media_pad, +making the struct media_pad pointer the canonical way to store and pass link references. Pads have flags that describe the pad capabilities and state. @@ -104,7 +104,7 @@ Pads have flags that describe the pad capabilities and state. Links ^^^^^ -Links are represented by a struct :c:type:`media_link` instance, +Links are represented by a struct media_link instance, defined in ``include/media/media-entity.h``. There are two types of links: **1. pad to pad links**: @@ -187,7 +187,7 @@ Use count and power handling Due to the wide differences between drivers regarding power management needs, the media controller does not implement power management. However, -the struct :c:type:`media_entity` includes a ``use_count`` +the struct media_entity includes a ``use_count`` field that media drivers can use to track the number of users of every entity for power management needs. @@ -213,11 +213,11 @@ prevent link states from being modified during streaming by calling The function will mark all entities connected to the given entity through enabled links, either directly or indirectly, as streaming. -The struct :c:type:`media_pipeline` instance pointed to by +The struct media_pipeline instance pointed to by the pipe argument will be stored in every entity in the pipeline. -Drivers should embed the struct :c:type:`media_pipeline` +Drivers should embed the struct media_pipeline in higher-level pipeline structures and can then access the -pipeline through the struct :c:type:`media_entity` +pipeline through the struct media_entity pipe field. Calls to :c:func:`media_pipeline_start()` can be nested. diff --git a/Documentation/driver-api/media/v4l2-controls.rst b/Documentation/driver-api/media/v4l2-controls.rst index 5129019afb49..77f42ea3bac7 100644 --- a/Documentation/driver-api/media/v4l2-controls.rst +++ b/Documentation/driver-api/media/v4l2-controls.rst @@ -27,7 +27,7 @@ V4L2 specification with respect to controls in a central place. And to make life as easy as possible for the driver developer. Note that the control framework relies on the presence of a struct -:c:type:`v4l2_device` for V4L2 drivers and struct :c:type:`v4l2_subdev` for +:c:type:`v4l2_device` for V4L2 drivers and struct v4l2_subdev for sub-device drivers. diff --git a/Documentation/driver-api/media/v4l2-dev.rst b/Documentation/driver-api/media/v4l2-dev.rst index 63c064837c00..666330af31ed 100644 --- a/Documentation/driver-api/media/v4l2-dev.rst +++ b/Documentation/driver-api/media/v4l2-dev.rst @@ -67,7 +67,7 @@ You should also set these fields of :c:type:`video_device`: file operation is called this lock will be taken by the core and released afterwards. See the next section for more details. -- :c:type:`video_device`->queue: a pointer to the struct :c:type:`vb2_queue` +- :c:type:`video_device`->queue: a pointer to the struct vb2_queue associated with this device node. If queue is not ``NULL``, and queue->lock is not ``NULL``, then queue->lock is used for the queuing ioctls (``VIDIOC_REQBUFS``, ``CREATE_BUFS``, @@ -81,7 +81,7 @@ You should also set these fields of :c:type:`video_device`: - :c:type:`video_device`->prio: keeps track of the priorities. Used to implement ``VIDIOC_G_PRIORITY`` and ``VIDIOC_S_PRIORITY``. - If left to ``NULL``, then it will use the struct :c:type:`v4l2_prio_state` + If left to ``NULL``, then it will use the struct v4l2_prio_state in :c:type:`v4l2_device`. If you want to have a separate priority state per (group of) device node(s), then you can point it to your own struct :c:type:`v4l2_prio_state`. @@ -95,7 +95,7 @@ You should also set these fields of :c:type:`video_device`: but it is used by both a raw video PCI device (cx8800) and a MPEG PCI device (cx8802). Since the :c:type:`v4l2_device` cannot be associated with two PCI devices at the same time it is setup without a parent device. But when the - struct :c:type:`video_device` is initialized you **do** know which parent + struct video_device is initialized you **do** know which parent PCI device to use and so you set ``dev_device`` to the correct PCI device. If you use :c:type:`v4l2_ioctl_ops`, then you should set @@ -138,7 +138,7 @@ ioctls and locking ------------------ The V4L core provides optional locking services. The main service is the -lock field in struct :c:type:`video_device`, which is a pointer to a mutex. +lock field in struct video_device, which is a pointer to a mutex. If you set this pointer, then that will be used by unlocked_ioctl to serialize all ioctls. diff --git a/Documentation/driver-api/media/v4l2-device.rst b/Documentation/driver-api/media/v4l2-device.rst index 5e25bf182c18..7bd9c45f551b 100644 --- a/Documentation/driver-api/media/v4l2-device.rst +++ b/Documentation/driver-api/media/v4l2-device.rst @@ -3,7 +3,7 @@ V4L2 device instance -------------------- -Each device instance is represented by a struct :c:type:`v4l2_device`. +Each device instance is represented by a struct v4l2_device. Very simple devices can just allocate this struct, but most of the time you would embed this struct inside a larger struct. @@ -18,9 +18,9 @@ dev->driver_data field is ``NULL``, it will be linked to Drivers that want integration with the media device framework need to set dev->driver_data manually to point to the driver-specific device structure -that embed the struct :c:type:`v4l2_device` instance. This is achieved by a +that embed the struct v4l2_device instance. This is achieved by a ``dev_set_drvdata()`` call before registering the V4L2 device instance. -They must also set the struct :c:type:`v4l2_device` mdev field to point to a +They must also set the struct v4l2_device mdev field to point to a properly initialized and registered :c:type:`media_device` instance. If :c:type:`v4l2_dev <v4l2_device>`\ ->name is empty then it will be set to a diff --git a/Documentation/driver-api/media/v4l2-event.rst b/Documentation/driver-api/media/v4l2-event.rst index a4b7ae2b94d8..5b8254eba7da 100644 --- a/Documentation/driver-api/media/v4l2-event.rst +++ b/Documentation/driver-api/media/v4l2-event.rst @@ -44,18 +44,18 @@ such objects. So to summarize: -- struct :c:type:`v4l2_fh` has two lists: one of the ``subscribed`` events, +- struct v4l2_fh has two lists: one of the ``subscribed`` events, and one of the ``available`` events. -- struct :c:type:`v4l2_subscribed_event` has a ringbuffer of raised +- struct v4l2_subscribed_event has a ringbuffer of raised (pending) events of that particular type. -- If struct :c:type:`v4l2_subscribed_event` is associated with a specific +- If struct v4l2_subscribed_event is associated with a specific object, then that object will have an internal list of - struct :c:type:`v4l2_subscribed_event` so it knows who subscribed an + struct v4l2_subscribed_event so it knows who subscribed an event to that object. -Furthermore, the internal struct :c:type:`v4l2_subscribed_event` has +Furthermore, the internal struct v4l2_subscribed_event has ``merge()`` and ``replace()`` callbacks which drivers can set. These callbacks are called when a new event is raised and there is no more room. diff --git a/Documentation/driver-api/media/v4l2-fh.rst b/Documentation/driver-api/media/v4l2-fh.rst index 4c62b19af744..3eeaa8da0c9e 100644 --- a/Documentation/driver-api/media/v4l2-fh.rst +++ b/Documentation/driver-api/media/v4l2-fh.rst @@ -3,11 +3,11 @@ V4L2 File handlers ------------------ -struct :c:type:`v4l2_fh` provides a way to easily keep file handle specific +struct v4l2_fh provides a way to easily keep file handle specific data that is used by the V4L2 framework. .. attention:: - New drivers must use struct :c:type:`v4l2_fh` + New drivers must use struct v4l2_fh since it is also used to implement priority handling (:ref:`VIDIOC_G_PRIORITY`). @@ -16,11 +16,11 @@ whether a driver uses :c:type:`v4l2_fh` as its ``file->private_data`` pointer by testing the ``V4L2_FL_USES_V4L2_FH`` bit in :c:type:`video_device`->flags. This bit is set whenever :c:func:`v4l2_fh_init` is called. -struct :c:type:`v4l2_fh` is allocated as a part of the driver's own file handle +struct v4l2_fh is allocated as a part of the driver's own file handle structure and ``file->private_data`` is set to it in the driver's ``open()`` function by the driver. -In many cases the struct :c:type:`v4l2_fh` will be embedded in a larger +In many cases the struct v4l2_fh will be embedded in a larger structure. In that case you should call: #) :c:func:`v4l2_fh_init` and :c:func:`v4l2_fh_add` in ``open()`` @@ -102,18 +102,18 @@ Below is a short description of the :c:type:`v4l2_fh` functions used: memory can be freed. -If struct :c:type:`v4l2_fh` is not embedded, then you can use these helper functions: +If struct v4l2_fh is not embedded, then you can use these helper functions: :c:func:`v4l2_fh_open <v4l2_fh_open>` (struct file \*filp) -- This allocates a struct :c:type:`v4l2_fh`, initializes it and adds it to - the struct :c:type:`video_device` associated with the file struct. +- This allocates a struct v4l2_fh, initializes it and adds it to + the struct video_device associated with the file struct. :c:func:`v4l2_fh_release <v4l2_fh_release>` (struct file \*filp) -- This deletes it from the struct :c:type:`video_device` associated with the +- This deletes it from the struct video_device associated with the file struct, uninitialised the :c:type:`v4l2_fh` and frees it. These two functions can be plugged into the v4l2_file_operation's ``open()`` diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst index 6248ea99e979..bb5b1a7cdfd9 100644 --- a/Documentation/driver-api/media/v4l2-subdev.rst +++ b/Documentation/driver-api/media/v4l2-subdev.rst @@ -110,7 +110,7 @@ pads: err = media_entity_pads_init(&sd->entity, npads, pads); The pads array must have been previously initialized. There is no need to -manually set the struct :c:type:`media_entity` function and name fields, but the +manually set the struct media_entity function and name fields, but the revision field must be initialized if needed. A reference to the entity will be automatically acquired/released when the diff --git a/Documentation/driver-api/regulator.rst b/Documentation/driver-api/regulator.rst index 520da0a5251d..b43c78eb24d8 100644 --- a/Documentation/driver-api/regulator.rst +++ b/Documentation/driver-api/regulator.rst @@ -116,7 +116,7 @@ core, providing operations structures to the core. A notifier interface allows error conditions to be reported to the core. Registration should be triggered by explicit setup done by the platform, -supplying a struct :c:type:`regulator_init_data` for the regulator +supplying a struct regulator_init_data for the regulator containing constraint and supply information. Machine interface @@ -144,7 +144,7 @@ a given system, for example supporting higher supply voltages than the consumers are rated for. This is done at driver registration time` by providing a -struct :c:type:`regulation_constraints`. +struct regulation_constraints. The constraints may also specify an initial configuration for the regulator in the constraints, which is particularly useful for use with diff --git a/Documentation/driver-api/usb/URB.rst b/Documentation/driver-api/usb/URB.rst index 1e4abc896a0d..a182c0f5e38a 100644 --- a/Documentation/driver-api/usb/URB.rst +++ b/Documentation/driver-api/usb/URB.rst @@ -47,7 +47,7 @@ called USB Request Block, or URB for short. The URB structure ================= -Some of the fields in struct :c:type:`urb` are:: +Some of the fields in struct urb are:: struct urb { diff --git a/Documentation/driver-api/usb/gadget.rst b/Documentation/driver-api/usb/gadget.rst index 3e8a3809c0b8..09396edd6131 100644 --- a/Documentation/driver-api/usb/gadget.rst +++ b/Documentation/driver-api/usb/gadget.rst @@ -176,9 +176,9 @@ Kernel Mode Gadget API Gadget drivers declare themselves through a struct :c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration -for a struct :c:type:`usb_gadget`. The response to a set_configuration usually -involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by -the gadget, and submitting one or more struct :c:type:`usb_request` buffers to +for a struct usb_gadget. The response to a set_configuration usually +involves enabling one or more of the struct usb_ep objects exposed by +the gadget, and submitting one or more struct usb_request buffers to transfer data. Understand those four data types, and their operations, and you will understand how this API works. @@ -339,8 +339,8 @@ multi-configuration devices (also more than one function, but not necessarily sharing a given configuration). There is however an optional framework which makes it easier to reuse and combine functions. -Devices using this framework provide a struct :c:type:`usb_composite_driver`, -which in turn provides one or more struct :c:type:`usb_configuration` +Devices using this framework provide a struct usb_composite_driver, +which in turn provides one or more struct usb_configuration instances. Each such configuration includes at least one struct :c:type:`usb_function`, which packages a user visible role such as "network link" or "mass storage device". Management functions may also exist, diff --git a/Documentation/driver-api/usb/hotplug.rst b/Documentation/driver-api/usb/hotplug.rst index 79663e653ca1..c1e13107c50e 100644 --- a/Documentation/driver-api/usb/hotplug.rst +++ b/Documentation/driver-api/usb/hotplug.rst @@ -122,7 +122,7 @@ and their quirks, might have a MODULE_DEVICE_TABLE like this:: Most USB device drivers should pass these tables to the USB subsystem as well as to the module management subsystem. Not all, though: some driver frameworks connect using interfaces layered over USB, and so they won't -need such a struct :c:type:`usb_driver`. +need such a struct usb_driver. Drivers that connect directly to the USB subsystem should be declared something like this:: diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 423c5a0daf45..4f858b38a412 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -437,7 +437,7 @@ FS_IOC_SET_ENCRYPTION_POLICY The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an empty directory or verifies that a directory or regular file already has the specified encryption policy. It takes in a pointer to a -:c:type:`struct fscrypt_policy_v1` or a :c:type:`struct +struct fscrypt_policy_v1 or a :c:type:`struct fscrypt_policy_v2`, defined as follows:: #define FSCRYPT_POLICY_V1 0 @@ -508,7 +508,7 @@ This structure must be initialized as follows: replaced with ``master_key_identifier``, which is longer and cannot be arbitrarily chosen. Instead, the key must first be added using `FS_IOC_ADD_ENCRYPTION_KEY`_. Then, the ``key_spec.u.identifier`` - the kernel returned in the :c:type:`struct fscrypt_add_key_arg` must + the kernel returned in the struct fscrypt_add_key_arg must be used as the ``master_key_identifier`` in the :c:type:`struct fscrypt_policy_v2`. @@ -590,7 +590,7 @@ FS_IOC_GET_ENCRYPTION_POLICY_EX The FS_IOC_GET_ENCRYPTION_POLICY_EX ioctl retrieves the encryption policy, if any, for a directory or regular file. No additional permissions are required beyond the ability to open the file. It -takes in a pointer to a :c:type:`struct fscrypt_get_policy_ex_arg`, +takes in a pointer to a struct fscrypt_get_policy_ex_arg, defined as follows:: struct fscrypt_get_policy_ex_arg { @@ -680,7 +680,7 @@ the filesystem, making all files on the filesystem which were encrypted using that key appear "unlocked", i.e. in plaintext form. It can be executed on any file or directory on the target filesystem, but using the filesystem's root directory is recommended. It takes in -a pointer to a :c:type:`struct fscrypt_add_key_arg`, defined as +a pointer to a struct fscrypt_add_key_arg, defined as follows:: struct fscrypt_add_key_arg { @@ -710,7 +710,7 @@ follows:: __u8 raw[]; }; -:c:type:`struct fscrypt_add_key_arg` must be zeroed, then initialized +struct fscrypt_add_key_arg must be zeroed, then initialized as follows: - If the key is being added for use by v1 encryption policies, then @@ -860,7 +860,7 @@ The FS_IOC_REMOVE_ENCRYPTION_KEY ioctl removes a claim to a master encryption key from the filesystem, and possibly removes the key itself. It can be executed on any file or directory on the target filesystem, but using the filesystem's root directory is recommended. -It takes in a pointer to a :c:type:`struct fscrypt_remove_key_arg`, +It takes in a pointer to a struct fscrypt_remove_key_arg, defined as follows:: struct fscrypt_remove_key_arg { @@ -1149,7 +1149,7 @@ Encryption context ------------------ An encryption policy is represented on-disk by a :c:type:`struct -fscrypt_context_v1` or a :c:type:`struct fscrypt_context_v2`. It is +fscrypt_context_v1` or a struct fscrypt_context_v2. It is up to individual filesystems to decide where to store it, but normally it would be stored in a hidden extended attribute. It should *not* be exposed by the xattr-related system calls such as getxattr() and diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index 6c8944f6f0f7..895e9711ed88 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -84,7 +84,7 @@ FS_IOC_ENABLE_VERITY -------------------- The FS_IOC_ENABLE_VERITY ioctl enables fs-verity on a file. It takes -in a pointer to a :c:type:`struct fsverity_enable_arg`, defined as +in a pointer to a struct fsverity_enable_arg, defined as follows:: struct fsverity_enable_arg { diff --git a/Documentation/sound/designs/tracepoints.rst b/Documentation/sound/designs/tracepoints.rst index 78bc5572f829..b0a7e3010187 100644 --- a/Documentation/sound/designs/tracepoints.rst +++ b/Documentation/sound/designs/tracepoints.rst @@ -34,20 +34,20 @@ substream. In this procedure, PCM hardware parameters are decided by interaction between applications and ALSA PCM core. Once decided, runtime of the PCM substream keeps the parameters. -The parameters are described in :c:type:`struct snd_pcm_hw_params`. This +The parameters are described in struct snd_pcm_hw_params. This structure includes several types of parameters. Applications set preferable value to these parameters, then execute ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE or SNDRV_PCM_IOCTL_HW_PARAMS. The former is used just for refining available set of parameters. The latter is used for an actual decision of the parameters. -The :c:type:`struct snd_pcm_hw_params` structure has below members: +The struct snd_pcm_hw_params structure has below members: ``flags`` Configurable. ALSA PCM core and some drivers handle this flag to select convenient parameters or change their behaviour. ``masks`` Configurable. This type of parameter is described in - :c:type:`struct snd_mask` and represent mask values. As of PCM protocol + struct snd_mask and represent mask values. As of PCM protocol v2.0.13, three types are defined. - SNDRV_PCM_HW_PARAM_ACCESS @@ -55,7 +55,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: - SNDRV_PCM_HW_PARAM_SUBFORMAT ``intervals`` Configurable. This type of parameter is described in - :c:type:`struct snd_interval` and represent values with a range. As of + struct snd_interval and represent values with a range. As of PCM protocol v2.0.13, twelve types are defined. - SNDRV_PCM_HW_PARAM_SAMPLE_BITS @@ -78,7 +78,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: are going to be changed. ``cmask`` Read-only. After returning from ioctl(2), buffer in user space for - :c:type:`struct snd_pcm_hw_params` includes result of each operation. + struct snd_pcm_hw_params includes result of each operation. This mask represents which mask/interval parameter is actually changed. ``info`` Read-only. This represents hardware/driver capabilities as bit flags @@ -110,10 +110,10 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: value to this parameter but some drivers intentionally set zero with a care of hardware design or data transmission protocol. -ALSA PCM core handles buffer of :c:type:`struct snd_pcm_hw_params` when +ALSA PCM core handles buffer of struct snd_pcm_hw_params when applications execute ioctl(2) with SNDRV_PCM_HW_REFINE or SNDRV_PCM_HW_PARAMS. Parameters in the buffer are changed according to -:c:type:`struct snd_pcm_hardware` and rules of constraints in the runtime. The +struct snd_pcm_hardware and rules of constraints in the runtime. The structure describes capabilities of handled hardware. The rules describes dependencies on which a parameter is decided according to several parameters. A rule has a callback function, and drivers can register arbitrary functions @@ -121,17 +121,17 @@ to compute the target parameter. ALSA PCM core registers some rules to the runtime as a default. Each driver can join in the interaction as long as it prepared for two stuffs -in a callback of :c:type:`struct snd_pcm_ops.open`. +in a callback of struct snd_pcm_ops.open. 1. In the callback, drivers are expected to change a member of - :c:type:`struct snd_pcm_hardware` type in the runtime, according to + struct snd_pcm_hardware type in the runtime, according to capacities of corresponding hardware. 2. In the same callback, drivers are also expected to register additional rules of constraints into the runtime when several parameters have dependencies due to hardware design. The driver can refers to result of the interaction in a callback of -:c:type:`struct snd_pcm_ops.hw_params`, however it should not change the +struct snd_pcm_ops.hw_params, however it should not change the content. Tracepoints in this category are designed to trace changes of the @@ -163,7 +163,7 @@ fields are different according to type of the parameter. For parameters of mask type, the fields represent hexadecimal dump of content of the parameter. For parameters of interval type, the fields represent values of each member of ``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in -:c:type:`struct snd_interval` in this order. +struct snd_interval in this order. Tracepoints in drivers ====================== diff --git a/Documentation/sphinx/parse-headers.pl b/Documentation/sphinx/parse-headers.pl index 00a69aceff44..1910079f984f 100755 --- a/Documentation/sphinx/parse-headers.pl +++ b/Documentation/sphinx/parse-headers.pl @@ -110,7 +110,7 @@ while (<IN>) { ) { my $s = $1; - $structs{$s} = "struct :c:type:`$s`\\ "; + $structs{$s} = "struct $s\\ "; next; } } diff --git a/Documentation/vm/ksm.rst b/Documentation/vm/ksm.rst index d1b7270ad55c..9e37add068e6 100644 --- a/Documentation/vm/ksm.rst +++ b/Documentation/vm/ksm.rst @@ -26,7 +26,7 @@ tree. If a KSM page is shared between less than ``max_page_sharing`` VMAs, the node of the stable tree that represents such KSM page points to a -list of :c:type:`struct rmap_item` and the ``page->mapping`` of the +list of struct rmap_item and the ``page->mapping`` of the KSM page points to the stable tree node. When the sharing passes this threshold, KSM adds a second dimension to diff --git a/Documentation/vm/memory-model.rst b/Documentation/vm/memory-model.rst index 769449734573..9daadf9faba1 100644 --- a/Documentation/vm/memory-model.rst +++ b/Documentation/vm/memory-model.rst @@ -24,7 +24,7 @@ whether it is possible to manually override that default. although it is still in use by several architectures. All the memory models track the status of physical page frames using -:c:type:`struct page` arranged in one or more arrays. +struct page arranged in one or more arrays. Regardless of the selected memory model, there exists one-to-one mapping between the physical page frame number (PFN) and the @@ -111,7 +111,7 @@ maps for non-volatile memory devices and deferred initialization of the memory map for larger systems. The SPARSEMEM model presents the physical memory as a collection of -sections. A section is represented with :c:type:`struct mem_section` +sections. A section is represented with struct mem_section that contains `section_mem_map` that is, logically, a pointer to an array of struct pages. However, it is stored with some other magic that aids the sections management. The section size and maximal number @@ -172,7 +172,7 @@ management. The virtually mapped memory map allows storing `struct page` objects for persistent memory devices in pre-allocated storage on those -devices. This storage is represented with :c:type:`struct vmem_altmap` +devices. This storage is represented with struct vmem_altmap that is eventually passed to vmemmap_populate() through a long chain of function calls. The vmemmap_populate() implementation may use the `vmem_altmap` along with :c:func:`vmemmap_alloc_block_buf` helper to diff --git a/mm/ksm.c b/mm/ksm.c index 9afccc36dbd2..0960750bb316 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -81,7 +81,7 @@ * different KSM page copy of that content * * Internally, the regular nodes, "dups" and "chains" are represented - * using the same :c:type:`struct stable_node` structure. + * using the same struct stable_node structure. * * In addition to the stable tree, KSM uses a second data structure called the * unstable tree: this tree holds pointers to pages which have been found to diff --git a/mm/memblock.c b/mm/memblock.c index 45f198750be9..670216826940 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -48,12 +48,12 @@ * boot regardless of the possible restrictions and memory hot(un)plug; * the ``physmem`` type is only available on some architectures. * - * Each region is represented by :c:type:`struct memblock_region` that + * Each region is represented by struct memblock_region that * defines the region extents, its attributes and NUMA node id on NUMA * systems. Every memory type is described by the :c:type:`struct * memblock_type` which contains an array of memory regions along with * the allocator metadata. The "memory" and "reserved" types are nicely - * wrapped with :c:type:`struct memblock`. This structure is statically + * wrapped with struct memblock. This structure is statically * initialized at build time. The region arrays are initially sized to * %INIT_MEMBLOCK_REGIONS for "memory" and %INIT_MEMBLOCK_RESERVED_REGIONS * for "reserved". The region array for "physmem" is initially sized to -- 2.26.2

1 0

[PATCH] ASoC: fsl_spdif: Add support for higher sample rates
by Shengjiu Wang 13 Oct '20

13 Oct '20

Add 88200Hz and 176400Hz sample rates support for TX. Add 88200Hz, 176400Hz, 192000Hz sample rates support for RX. Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> Signed-off-by: Viorel Suman <viorel.suman(a)nxp.com> --- sound/soc/fsl/fsl_spdif.c | 16 +++++++++++++--- sound/soc/fsl/fsl_spdif.h | 9 ++++++++- 2 files changed, 21 insertions(+), 4 deletions(-) diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c index b0f643fefe1e..f41496cf5b63 100644 --- a/sound/soc/fsl/fsl_spdif.c +++ b/sound/soc/fsl/fsl_spdif.c @@ -429,10 +429,18 @@ static int spdif_set_sample_rate(struct snd_pcm_substream *substream, rate = SPDIF_TXRATE_48000; csfs = IEC958_AES3_CON_FS_48000; break; + case 88200: + rate = SPDIF_TXRATE_88200; + csfs = IEC958_AES3_CON_FS_88200; + break; case 96000: rate = SPDIF_TXRATE_96000; csfs = IEC958_AES3_CON_FS_96000; break; + case 176400: + rate = SPDIF_TXRATE_176400; + csfs = IEC958_AES3_CON_FS_176400; + break; case 192000: rate = SPDIF_TXRATE_192000; csfs = IEC958_AES3_CON_FS_192000; @@ -827,7 +835,7 @@ static int fsl_spdif_rxrate_info(struct snd_kcontrol *kcontrol, uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; uinfo->count = 1; uinfo->value.integer.min = 16000; - uinfo->value.integer.max = 96000; + uinfo->value.integer.max = 192000; return 0; } @@ -1145,7 +1153,8 @@ static u32 fsl_spdif_txclk_caldiv(struct fsl_spdif_priv *spdif_priv, struct clk *clk, u64 savesub, enum spdif_txrate index, bool round) { - static const u32 rate[] = { 32000, 44100, 48000, 96000, 192000 }; + static const u32 rate[] = { 32000, 44100, 48000, 88200, 96000, 176400, + 192000, }; bool is_sysclk = clk_is_match(clk, spdif_priv->sysclk); u64 rate_ideal, rate_actual, sub; u32 arate; @@ -1205,7 +1214,8 @@ static u32 fsl_spdif_txclk_caldiv(struct fsl_spdif_priv *spdif_priv, static int fsl_spdif_probe_txclk(struct fsl_spdif_priv *spdif_priv, enum spdif_txrate index) { - static const u32 rate[] = { 32000, 44100, 48000, 96000, 192000 }; + static const u32 rate[] = { 32000, 44100, 48000, 88200, 96000, 176400, + 192000, }; struct platform_device *pdev = spdif_priv->pdev; struct device *dev = &pdev->dev; u64 savesub = 100000, ret; diff --git a/sound/soc/fsl/fsl_spdif.h b/sound/soc/fsl/fsl_spdif.h index e6c61e07bc1a..d5f1dfd58740 100644 --- a/sound/soc/fsl/fsl_spdif.h +++ b/sound/soc/fsl/fsl_spdif.h @@ -163,7 +163,9 @@ enum spdif_txrate { SPDIF_TXRATE_32000 = 0, SPDIF_TXRATE_44100, SPDIF_TXRATE_48000, + SPDIF_TXRATE_88200, SPDIF_TXRATE_96000, + SPDIF_TXRATE_176400, SPDIF_TXRATE_192000, }; #define SPDIF_TXRATE_MAX (SPDIF_TXRATE_192000 + 1) @@ -177,15 +179,20 @@ enum spdif_txrate { #define FSL_SPDIF_RATES_PLAYBACK (SNDRV_PCM_RATE_32000 | \ SNDRV_PCM_RATE_44100 | \ SNDRV_PCM_RATE_48000 | \ + SNDRV_PCM_RATE_88200 | \ SNDRV_PCM_RATE_96000 | \ + SNDRV_PCM_RATE_176400 | \ SNDRV_PCM_RATE_192000) #define FSL_SPDIF_RATES_CAPTURE (SNDRV_PCM_RATE_16000 | \ SNDRV_PCM_RATE_32000 | \ SNDRV_PCM_RATE_44100 | \ SNDRV_PCM_RATE_48000 | \ + SNDRV_PCM_RATE_88200 | \ SNDRV_PCM_RATE_64000 | \ - SNDRV_PCM_RATE_96000) + SNDRV_PCM_RATE_96000 | \ + SNDRV_PCM_RATE_176400 | \ + SNDRV_PCM_RATE_192000) #define FSL_SPDIF_FORMATS_PLAYBACK (SNDRV_PCM_FMTBIT_S16_LE | \ SNDRV_PCM_FMTBIT_S20_3LE | \ -- 2.27.0

4 5

error(no sound) over boundary time [src/pcm/pcm_dshare.c]
by GitHub issues - opened 13 Oct '20

13 Oct '20

alsa-project/alsa-lib issue #84 was opened from syuuha: there is an issue when we use pcm_dshare over boundary time, eg. will be no sound after 12 hours [src/pcm/pcm_dshare.c] Line 114: [before] /* calculate the size to transfer */ size = dshare->appl_ptr - dshare->last_appl_ptr; [after] /* calculate the size to transfer */ if (dshare->appl_ptr < dshare->last_appl_ptr) size = dshare->appl_ptr + (pcm->boundary - dshare->last_appl_ptr); else size = dshare->appl_ptr - dshare->last_appl_ptr; Issue URL : https://github.com/alsa-project/alsa-lib/issues/84 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH v7 00/14] Add Allwinner H3/H5/H6/A64 HDMI audio
by Clément Péron 12 Oct '20

12 Oct '20

Hi, Just some minor changes compare to v6. As explain in v6 there is no more HDMI soundcard, I will try to introduce a dedicated Allwinner soundcard in a next series. Clément Change since v6: - move set_channel_cfg() in first position - convert return value to decimal Change since v5: - Drop HDMI simple soundcard - Collect Chen-Yu Tsai tags - Configure channels from 9 to 15. - Remove DMA RX for H3/H5 - Fix Documentation for H3/H5 Change since v4: - add more comment on get_wss() and set_channel_cfg() patch - merge soundcard and DAI HDMI patches Change since v3: - add Samuel Holland patch to reconfigure FIFO_TX_REG when suspend is enabled - readd inversion to H6 LRCK sun50i_h6_i2s_set_soc_fmt() - Fix get_wss() for sun4i - Add a commit to fix checkpatch warning Change since v2: - rebase on next-20200918 - drop revert LRCK polarity patch - readd simple-audio-card,frame-inversion in dts - Add patch for changing set_chan_cfg params Change since v1: - rebase on next-20200828 - add revert LRCK polarity - remove all simple-audio-card,frame-inversion in dts - add Ondrej patches for Orange Pi board - Add arm64 defconfig patch Clément Péron (6): ASoC: sun4i-i2s: Change set_chan_cfg() params ASoC: sun4i-i2s: Change get_sr() and get_wss() to be more explicit ASoC: sun4i-i2s: Fix sun8i volatile regs ASoC: sun4i-i2s: fix coding-style for callback definition arm64: defconfig: Enable Allwinner i2s driver dt-bindings: sound: sun4i-i2s: Document H3 with missing RX channel possibility Jernej Skrabec (3): ASoC: sun4i-i2s: Add support for H6 I2S dt-bindings: ASoC: sun4i-i2s: Add H6 compatible arm64: dts: allwinner: h6: Add I2S1 node Marcus Cooper (4): ASoC: sun4i-i2s: Set sign extend sample ASoc: sun4i-i2s: Add 20 and 24 bit support arm64: dts: allwinner: a64: Add I2S2 node arm: dts: sunxi: h3/h5: Add I2S2 node Samuel Holland (1): ASoC: sun4i-i2s: Fix setting of FIFO modes .../sound/allwinner,sun4i-a10-i2s.yaml | 6 +- arch/arm/boot/dts/sunxi-h3-h5.dtsi | 13 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 14 + arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 13 + arch/arm64/configs/defconfig | 1 + sound/soc/sunxi/sun4i-i2s.c | 376 +++++++++++++++--- 6 files changed, 368 insertions(+), 55 deletions(-) -- 2.25.1

2 15

[PATCH v2 00/13] ASoC: Intel: Remove obsolete solutions and components
by Cezary Rojewski 12 Oct '20

12 Oct '20

Follow up to catpt series as mentioned in: [PATCH v10 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point https://www.spinics.net/lists/alsa-devel/msg116440.html As catpt is a direct replacement to sound/soc/intel/haswell, it leaves a lot of code redudant. The second legacy solution - baytrail - is deprecated for a long time by sound/soc/intel/atom with SOF flavor available too. This series addresses the redudancy and removes obsolete code. Along with the legacy solutions, all orphaned components are removed too. As a consequence, further cleanups are unlocked: sound/soc/intel/skylake becomes the sole user of processing code found in sound/soc/intel/common. Those are not part of this series. Changes in v2: - just a rebase so patch 04/13 applies cleanly - left the tags as no actual changes done in between Cezary Rojewski (13): ASoC: Intel: Remove haswell solution ASoC: Intel: Remove max98090 support for baytrail solution ASoC: Intel: Remove rt5640 support for baytrail solution ASoC: Intel: Remove baytrail solution ASoC: Intel: Remove SST ACPI component ASoC: Intel: Remove SST firmware components ASoC: Intel: Skylake: Unassign ram_read and read_write ops ASoC: Intel: Remove unused DSP operations ASoC: Intel: Remove unused DSP interface fields ASoC: Intel: Remove SST-legacy specific constants ASoC: Intel: Make atom components independent of sst-dsp ASoC: Intel: Remove sst_pdata structure ASoC: Intel: Remove sst_dsp_get_thread_context include/sound/soc-acpi-intel-match.h | 1 - include/trace/events/hswadsp.h | 385 --- sound/soc/intel/Kconfig | 26 - sound/soc/intel/Makefile | 1 - sound/soc/intel/atom/sst/sst.c | 1 - sound/soc/intel/atom/sst/sst.h | 7 + sound/soc/intel/atom/sst/sst_acpi.c | 1 - sound/soc/intel/atom/sst/sst_drv_interface.c | 3 - sound/soc/intel/atom/sst/sst_ipc.c | 1 - sound/soc/intel/atom/sst/sst_loader.c | 1 - sound/soc/intel/atom/sst/sst_pvt.c | 1 - sound/soc/intel/atom/sst/sst_stream.c | 1 - sound/soc/intel/baytrail/Makefile | 5 - sound/soc/intel/baytrail/sst-baytrail-dsp.c | 358 --- sound/soc/intel/baytrail/sst-baytrail-ipc.c | 772 ------ sound/soc/intel/baytrail/sst-baytrail-ipc.h | 64 - sound/soc/intel/baytrail/sst-baytrail-pcm.c | 459 ---- sound/soc/intel/boards/Kconfig | 25 - sound/soc/intel/boards/Makefile | 4 - sound/soc/intel/boards/byt-max98090.c | 182 -- sound/soc/intel/boards/byt-rt5640.c | 224 -- sound/soc/intel/boards/bytcht_es8316.c | 1 - sound/soc/intel/boards/bytcr_rt5640.c | 1 - sound/soc/intel/common/Makefile | 4 - .../intel/common/soc-acpi-intel-byt-match.c | 15 - sound/soc/intel/common/sst-acpi.c | 236 -- sound/soc/intel/common/sst-dsp-priv.h | 284 +-- sound/soc/intel/common/sst-dsp.c | 162 -- sound/soc/intel/common/sst-dsp.h | 222 -- sound/soc/intel/common/sst-firmware.c | 1273 ---------- sound/soc/intel/common/sst-ipc.c | 27 - sound/soc/intel/common/sst-ipc.h | 3 - sound/soc/intel/haswell/Makefile | 5 - sound/soc/intel/haswell/sst-haswell-dsp.c | 705 ------ sound/soc/intel/haswell/sst-haswell-ipc.c | 2222 ----------------- sound/soc/intel/haswell/sst-haswell-ipc.h | 527 ---- sound/soc/intel/haswell/sst-haswell-pcm.c | 1369 ---------- sound/soc/intel/skylake/bxt-sst.c | 2 - sound/soc/intel/skylake/cnl-sst.c | 4 +- sound/soc/intel/skylake/skl-sst-dsp.c | 2 +- sound/soc/intel/skylake/skl-sst-ipc.c | 2 +- sound/soc/intel/skylake/skl-sst.c | 2 - 42 files changed, 11 insertions(+), 9579 deletions(-) delete mode 100644 include/trace/events/hswadsp.h delete mode 100644 sound/soc/intel/baytrail/Makefile delete mode 100644 sound/soc/intel/baytrail/sst-baytrail-dsp.c delete mode 100644 sound/soc/intel/baytrail/sst-baytrail-ipc.c delete mode 100644 sound/soc/intel/baytrail/sst-baytrail-ipc.h delete mode 100644 sound/soc/intel/baytrail/sst-baytrail-pcm.c delete mode 100644 sound/soc/intel/boards/byt-max98090.c delete mode 100644 sound/soc/intel/boards/byt-rt5640.c delete mode 100644 sound/soc/intel/common/sst-acpi.c delete mode 100644 sound/soc/intel/common/sst-firmware.c delete mode 100644 sound/soc/intel/haswell/Makefile delete mode 100644 sound/soc/intel/haswell/sst-haswell-dsp.c delete mode 100644 sound/soc/intel/haswell/sst-haswell-ipc.c delete mode 100644 sound/soc/intel/haswell/sst-haswell-ipc.h delete mode 100644 sound/soc/intel/haswell/sst-haswell-pcm.c -- 2.17.1

7 24

[PATCH 00/25] ASoC: sun8i-codec: support for AIF2 and AIF3
by Samuel Holland 12 Oct '20

12 Oct '20

This series adds support the other two AIFs present in the sun8i codec, which can be used for codec2codec DAI links. This series first cleans up the DAPM component driver so there is an organized place to put the new widgets. Then it fills out the DAI driver, removing assumptions that were made for AIF1 (16 bits, 2 channels, certain clock inversions). Some new logic is required to handle 3 DAIs and the ADC/DAC sharing the same clock. Finally, it adds the new DAIs, and hooks them up with DAPM widgets and routes per the hardware topology. To minimize the number of patches in this series, related device tree patches (increasing #sound-dai-cells, adding new DAI links) will be sent separately. Samuel Holland (25): ASoC: sun8i-codec: Set up clock tree at probe time ASoC: sun8i-codec: Swap module clock/reset dependencies ASoC: sun8i-codec: Sort DAPM controls, widgets, and routes ASoC: sun8i-codec: Consistently name DAPM widgets and routes ASoC: sun8i-codec: Correct DAPM widget types ASoC: sun8i-codec: Fix AIF widget channel references ASoC: sun8i-codec: Enable AIF mono/stereo control ASoC: sun8i-codec: Use snd_soc_dai_get_drvdata ASoC: sun8i-codec: Prepare to extend the DAI driver ASoC: sun8i-codec: Program format before clock inversion ASoC: sun8i-codec: Enable all supported clock inversions ASoC: sun8i-codec: Program the correct word size ASoC: sun8i-codec: Round up the LRCK divisor ASoC: sun8i-codec: Correct the BCLK divisor calculation ASoC: sun8i-codec: Support the TDM slot binding ASoC: sun8i-codec: Enforce symmetric DAI parameters ASoC: sun8i-codec: Enable all supported sample rates ASoC: sun8i-codec: Automatically set the system sample rate ASoC: sun8i-codec: Constrain to compatible sample rates ASoC: sun8i-codec: Protect the clock rate while streams are open ASoC: sun8i-codec: Require an exact BCLK divisor match ASoC: sun8i-codec: Enable all supported PCM formats ASoC: sun8i-codec: Generalize AIF clock control ASoC: sun8i-codec: Add a DAI, widgets, and routes for AIF2 ASoC: sun8i-codec: Add a DAI, widgets, and routes for AIF3 sound/soc/sunxi/sun8i-codec.c | 1135 ++++++++++++++++++++++++++------- 1 file changed, 894 insertions(+), 241 deletions(-) -- 2.26.2

5 59

[PATCH v2] ALSA: hda: fix jack detection with Realtek codecs when in D3
by Kai Vehmanen 12 Oct '20

12 Oct '20

In case HDA controller becomes active, but codec is runtime suspended, jack detection is not successful and no interrupt is raised. This has been observed with multiple Realtek codecs and HDA controllers from different vendors. Bug does not occur if both codec and controller are active, or both are in suspend. Bug can be easily hit on desktop systems with no built-in speaker. The problem can be fixed by powering up the codec once after every controller runtime resume. Even if codec goes back to suspend later, the jack detection will continue to work. Add a flag to 'hda_codec' to describe codecs that require this flow from the controller driver. Modify __azx_runtime_resume() to use pm_request_resume() to make the intent clearer. Mark all Realtek codecs with the new forced_resume flag. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209379 Cc: Kailang Yang <kailang(a)realtek.com> Co-developed-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- include/sound/hda_codec.h | 1 + sound/pci/hda/hda_intel.c | 14 ++++++++------ sound/pci/hda/patch_realtek.c | 1 + 3 files changed, 10 insertions(+), 6 deletions(-) v1->v2: - simplified the for_each_codec block as per feedback from Takashi - clarified commit message that bug occurs when controller is resumed (feedback from Pierre) - moved forced_resume setting from alc_pre_init to alc_alloc_spec which seems more appropriate and removed the inline comments as those seem out-of-place in patch_realtek (other drivers may use the flag as well) diff --git a/include/sound/hda_codec.h b/include/sound/hda_codec.h index 0fea49bfc5e8..73827b7d17e0 100644 --- a/include/sound/hda_codec.h +++ b/include/sound/hda_codec.h @@ -253,6 +253,7 @@ struct hda_codec { unsigned int force_pin_prefix:1; /* Add location prefix */ unsigned int link_down_at_suspend:1; /* link down at runtime suspend */ unsigned int relaxed_resume:1; /* don't resume forcibly for jack */ + unsigned int forced_resume:1; /* forced resume for jack */ unsigned int mst_no_extra_pcms:1; /* no backup PCMs for DP-MST */ #ifdef CONFIG_PM diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 61e495187b1a..749b88090970 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1002,12 +1002,14 @@ static void __azx_runtime_resume(struct azx *chip, bool from_rt) azx_init_pci(chip); hda_intel_init_chip(chip, true); - if (status && from_rt) { - list_for_each_codec(codec, &chip->bus) - if (!codec->relaxed_resume && - (status & (1 << codec->addr))) - schedule_delayed_work(&codec->jackpoll_work, - codec->jackpoll_interval); + if (from_rt) { + list_for_each_codec(codec, &chip->bus) { + if (codec->relaxed_resume) + continue; + + if (codec->forced_resume || (status & (1 << codec->addr))) + pm_request_resume(hda_codec_dev(codec)); + } } /* power down again for link-controlled chips */ diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index f89506dffd5b..f2398721ac1e 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -1150,6 +1150,7 @@ static int alc_alloc_spec(struct hda_codec *codec, hda_nid_t mixer_nid) codec->single_adc_amp = 1; /* FIXME: do we need this for all Realtek codec models? */ codec->spdif_status_reset = 1; + codec->forced_resume = 1; codec->patch_ops = alc_patch_ops; err = alc_codec_rename_from_preset(codec); -- 2.28.0

2 1

[bug report] ASoC: Intel: catpt: Firmware loading and context restore
by Dan Carpenter 12 Oct '20

12 Oct '20

Hello Cezary Rojewski, The patch a9aa6fb3eb6c: "ASoC: Intel: catpt: Firmware loading and context restore" from Sep 29, 2020, leads to the following static checker warning: sound/soc/intel/catpt/loader.c:654 catpt_first_boot_firmware() warn: consider using resource_size() here sound/soc/intel/catpt/loader.c 638 int catpt_first_boot_firmware(struct catpt_dev *cdev) 639 { 640 struct resource *res; 641 int ret; 642 643 ret = catpt_boot_firmware(cdev, false); 644 if (ret) { 645 dev_err(cdev->dev, "basefw boot failed: %d\n", ret); 646 return ret; 647 } 648 649 /* restrict FW Core dump area */ 650 __request_region(&cdev->dram, 0, 0x200, NULL, 0); 651 /* restrict entire area following BASE_FW - highest offset in DRAM */ 652 for (res = cdev->dram.child; res->sibling; res = res->sibling) 653 ; 654 __request_region(&cdev->dram, res->end + 1, 655 cdev->dram.end - res->end, NULL, 0); ^^^^^^^^^^^^^^^^^^^^^^^^^ It's been years since I have seen one of these warnings. Back in the day we used have have a lot of off by one warnings because resource_size() is supposed to be calculated as "end - start + 1". But here we are calculating "dram.end - res->end" so I'm not sure if the math is correct or not. This is very new code so hopefully you know the answer off the top of your head? 656 657 ret = catpt_ipc_get_mixer_stream_info(cdev, &cdev->mixer); 658 if (ret) 659 return CATPT_IPC_ERROR(ret); 660 661 ret = catpt_arm_stream_templates(cdev); 662 if (ret) { 663 dev_err(cdev->dev, "arm templates failed: %d\n", ret); 664 return ret; 665 } 666 667 /* update dram pg for scratch and restricted regions */ 668 catpt_dsp_update_srampge(cdev, &cdev->dram, cdev->spec->dram_mask); 669 670 return 0; 671 } regards, dan carpenter

2 1

[PATCH] dt-bindings: sound: sun8i-a33-codec: Add Allwinner A64 codec compatible fallback
by Clément Péron 12 Oct '20

12 Oct '20

make dtbs_check report a warning because the documentation for the A64 codec compatible is missing. The A64 codec compatible is actually a simple fallback to the A33. Reflect this in the dt-bindings Documentation. Signed-off-by: Clément Péron <peron.clem(a)gmail.com> --- .../bindings/sound/allwinner,sun8i-a33-codec.yaml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml index 55d28268d2f4..e78a22496e7c 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml @@ -15,7 +15,11 @@ properties: const: 0 compatible: - const: allwinner,sun8i-a33-codec + oneOf: + - const: allwinner,sun8i-a33-codec + - items: + - const: allwinner,sun50i-a64-codec + - const: allwinner,sun8i-a33-codec reg: maxItems: 1 -- 2.25.1

2 2

Can't aplay/arecord simultaneously inside and outside of linux container
by GitHub issues - opened 12 Oct '20

12 Oct '20

alsa-project/alsa-utils issue #62 was opened from fearless-fan: Hi, I run into a problem that can't aplay/arecord simultaneously inside and outside of linux container. Steps to reproduce: 1. go into container's shell and exec a record command. ~ # lxc-attach -n Default -P /tmp/run/lxc / # arecord -d 60 /tmp/test.wav & / # Recording WAVE '/tmp/test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono / # ps PID USER TIME COMMAND 1 root 0:00 /sbin/init 3 root 0:00 /bin/sh 1519 root 0:00 arecord -d 60 /tmp/test.wav 1520 root 0:00 /bin/ash 1521 root 0:00 ps 2. exit and exec another record command outside of container / # exit ~ # arecord -d 60 /tmp/test.wav & ~ # ALSA lib pcm_dsnoop.c:641:(snd_pcm_dsnoop_open) unable to open slave arecord: main:830: audio open error: Device or resource busy [1]+ Done(1) arecord -d 60 /tmp/test.wav 3. playback has same problem as below ALSA lib pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slave aplay: main:830: audio open error: Device or resource busy Expect: It should be allowed to play/record simultaneously inside and outside of linux container. Here's my asound.conf: ~ # cat etc/asound.conf pcm.asymed { type asym playback.pcm "dmix:0,0" capture.pcm "dsnoop:0,0" } pcm.!default { type plug slave.pcm "asymed" } ctl.!default { type hw card 0 } Is there anyone has experience of how to address it? Thank you. Issue URL : https://github.com/alsa-project/alsa-utils/issues/62 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH] ASoC: Intel: Do not load legacy SST driver on BYT when SND_SOC_SOF_BAYTRAIL is enabled
by Hans de Goede 12 Oct '20

12 Oct '20

The legacy 80860F28 / sst_acpi_baytrail_desc match in sst_acpi_match is already conditional on the the newer SND_SST_IPC_ACPI driver not being enabled. But now that we have an even newer driver in the form of SOF support for BYT devices, we also need to take this into account, so we also must not include the sst_acpi_baytrail_desc match when SND_SOC_SOF_BAYTRAIL is enabled. This fixes snd-soc-sst-acpi binding to the 80860F28 platform device, blocking snd-sof-acpi from binding, which breaks audio support. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- sound/soc/intel/common/sst-acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/common/sst-acpi.c b/sound/soc/intel/common/sst-acpi.c index 5854868650b9..b4b2e1e0e845 100644 --- a/sound/soc/intel/common/sst-acpi.c +++ b/sound/soc/intel/common/sst-acpi.c @@ -198,7 +198,7 @@ static struct sst_acpi_desc sst_acpi_broadwell_desc = { .dma_size = SST_LPT_DSP_DMA_SIZE, }; -#if !IS_ENABLED(CONFIG_SND_SST_IPC_ACPI) +#if !IS_ENABLED(CONFIG_SND_SST_IPC_ACPI) && !IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL) static struct sst_acpi_desc sst_acpi_baytrail_desc = { .drv_name = "baytrail-pcm-audio", .machines = snd_soc_acpi_intel_baytrail_legacy_machines, @@ -214,7 +214,7 @@ static struct sst_acpi_desc sst_acpi_baytrail_desc = { static const struct acpi_device_id sst_acpi_match[] = { { "INT33C8", (unsigned long)&sst_acpi_haswell_desc }, { "INT3438", (unsigned long)&sst_acpi_broadwell_desc }, -#if !IS_ENABLED(CONFIG_SND_SST_IPC_ACPI) +#if !IS_ENABLED(CONFIG_SND_SST_IPC_ACPI) && !IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL) { "80860F28", (unsigned long)&sst_acpi_baytrail_desc }, #endif { } -- 2.28.0

2 4

[PATCH 0/5] ASoC: Mediatek: Add support for MT8192 SoC
by Jiaxin Yu 12 Oct '20

12 Oct '20

This series of patches adds support for Mediatek AFE for MT8192 SoC. At the same time, the calibration function of MT6359 is completed with real machine driver. The patch is based on broonie tree "for-next" branch. Jiaxin Yu (5): ASoC: mediatek: mt6359: add the calibration functions ASoC: mediatek: mt8192: add platform driver dt-bindings: mediatek: mt8192: add audio afe document ASoC: mediatek: mt8192: add machine driver with mt6359, rt1015 and rt5682 dt-bindings: mediatek: mt8192: add mt8192-mt6358-rt1015-rt5682 document .../bindings/sound/mt8192-afe-pcm.yaml | 98 + .../sound/mt8192-mt6359-rt1015-rt5682.yaml | 44 + sound/soc/codecs/mt6359.c | 110 + sound/soc/codecs/mt6359.h | 7 + sound/soc/mediatek/Kconfig | 23 + sound/soc/mediatek/Makefile | 1 + sound/soc/mediatek/common/mtk-afe-fe-dai.c | 13 +- sound/soc/mediatek/common/mtk-base-afe.h | 1 + sound/soc/mediatek/mt8192/Makefile | 16 + sound/soc/mediatek/mt8192/mt8192-afe-clk.c | 669 ++++ sound/soc/mediatek/mt8192/mt8192-afe-clk.h | 244 ++ sound/soc/mediatek/mt8192/mt8192-afe-common.h | 170 + .../soc/mediatek/mt8192/mt8192-afe-control.c | 163 + sound/soc/mediatek/mt8192/mt8192-afe-gpio.c | 306 ++ sound/soc/mediatek/mt8192/mt8192-afe-gpio.h | 19 + sound/soc/mediatek/mt8192/mt8192-afe-pcm.c | 2389 +++++++++++++ sound/soc/mediatek/mt8192/mt8192-dai-adda.c | 1489 ++++++++ sound/soc/mediatek/mt8192/mt8192-dai-i2s.c | 2139 +++++++++++ sound/soc/mediatek/mt8192/mt8192-dai-pcm.c | 409 +++ sound/soc/mediatek/mt8192/mt8192-dai-tdm.c | 778 ++++ .../mediatek/mt8192/mt8192-interconnection.h | 65 + .../mt8192/mt8192-mt6359-rt1015-rt5682.c | 1058 ++++++ sound/soc/mediatek/mt8192/mt8192-reg.h | 3131 +++++++++++++++++ 23 files changed, 13338 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml create mode 100644 Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml create mode 100644 sound/soc/mediatek/mt8192/Makefile create mode 100644 sound/soc/mediatek/mt8192/mt8192-afe-clk.c create mode 100644 sound/soc/mediatek/mt8192/mt8192-afe-clk.h create mode 100644 sound/soc/mediatek/mt8192/mt8192-afe-common.h create mode 100644 sound/soc/mediatek/mt8192/mt8192-afe-control.c create mode 100644 sound/soc/mediatek/mt8192/mt8192-afe-gpio.c create mode 100644 sound/soc/mediatek/mt8192/mt8192-afe-gpio.h create mode 100644 sound/soc/mediatek/mt8192/mt8192-afe-pcm.c create mode 100644 sound/soc/mediatek/mt8192/mt8192-dai-adda.c create mode 100644 sound/soc/mediatek/mt8192/mt8192-dai-i2s.c create mode 100644 sound/soc/mediatek/mt8192/mt8192-dai-pcm.c create mode 100644 sound/soc/mediatek/mt8192/mt8192-dai-tdm.c create mode 100644 sound/soc/mediatek/mt8192/mt8192-interconnection.h create mode 100644 sound/soc/mediatek/mt8192/mt8192-mt6359-rt1015-rt5682.c create mode 100644 sound/soc/mediatek/mt8192/mt8192-reg.h -- 2.18.0

3 12

Re: [PATCH 07/10] ALSA: firewire-lib: code refactoring for data block calculation
by MICHAEL Mosier 11 Oct '20

11 Oct '20

👋 hello I see our work has brought us together once again

1 0

Buggy hardware mixing
by Kevin Maciel 11 Oct '20

11 Oct '20

Hi all, I was referred here from the #alsa irc channel on freenode. I've been having issues with hardware mixing in ALSA since I started using Linux at least 10 years ago. Sometimes when I am trying to play multiple audio sources at once, one source will stop producing sound or all sound will all of a sudden turn into a mash of loud, jumbled noise. This has occurred across every combination of hardware and distribution of Linux I have used for my personal computers. I was trying to set up a custom dmix configuration to work around the problem, but I could not get multiple audio sources to play with my custom dmix definition. It seems to work if I use dmix:CARD=xxx, but I would like to set my own period_size and other such settings. I was told it is a better idea to try to figure out what the problem is with hardware mixing than to try to work around it with dmix. So here we are. I always thought this was a known problem and that hardware mixing by default was considered "new" or experimental. Thanks

1 0

snd_pcm_status() does not update status->avail
by Jonas Holmberg 09 Oct '20

09 Oct '20

Hi, I have a problem with status->avail not being updated when using multiple extplug plugins and softvol. I managed to get it to work with the following patch: diff --git a/src/pcm/pcm_plugin.c b/src/pcm/pcm_plugin.c index ea60eb98..89e819d6 100644 --- a/src/pcm/pcm_plugin.c +++ b/src/pcm/pcm_plugin.c @@ -551,6 +551,8 @@ static int snd_pcm_plugin_status(snd_pcm_t *pcm, snd_pcm_status_t * status) return err; status->appl_ptr = *pcm->appl.ptr; status->hw_ptr = *pcm->hw.ptr; + status->avail = snd_pcm_mmap_capture_avail(pcm); + status->delay = snd_pcm_mmap_capture_delay(pcm); return 0; } My question is if this is the correct solution? BR /Jonas

2 3

[PATCH 1/1] ALSA: hda: fix jack detection with Realtek codecs when in D3
by Kai Vehmanen 09 Oct '20

09 Oct '20

In case HDA controller is active, but codec is runtime suspended, jack detection is not successful and no interrupt is raised. This has been observed with multiple Realtek codecs and HDA controllers from different vendors. Bug does not occur if both codec and controller are active, or both are in suspend. Bug can be easily hit on desktop systems with no built-in speaker. The problem can be fixed by powering up the codec once after every controller runtime resume. Even if codec goes back to suspend, the jack detection will now work. Add a flag to 'hda_codec' to describe codecs that require this flow from the controller driver. Mark all Realtek codecs with this flag. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209379 Cc: Kailang Yang <kailang(a)realtek.com> Co-developed-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- include/sound/hda_codec.h | 1 + sound/pci/hda/hda_intel.c | 8 ++++++-- sound/pci/hda/patch_realtek.c | 6 ++++++ 3 files changed, 13 insertions(+), 2 deletions(-) diff --git a/include/sound/hda_codec.h b/include/sound/hda_codec.h index 0fea49bfc5e8..73827b7d17e0 100644 --- a/include/sound/hda_codec.h +++ b/include/sound/hda_codec.h @@ -253,6 +253,7 @@ struct hda_codec { unsigned int force_pin_prefix:1; /* Add location prefix */ unsigned int link_down_at_suspend:1; /* link down at runtime suspend */ unsigned int relaxed_resume:1; /* don't resume forcibly for jack */ + unsigned int forced_resume:1; /* forced resume for jack */ unsigned int mst_no_extra_pcms:1; /* no backup PCMs for DP-MST */ #ifdef CONFIG_PM diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 61e495187b1a..cfc073c992e7 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1002,12 +1002,16 @@ static void __azx_runtime_resume(struct azx *chip, bool from_rt) azx_init_pci(chip); hda_intel_init_chip(chip, true); - if (status && from_rt) { - list_for_each_codec(codec, &chip->bus) + if (from_rt) { + list_for_each_codec(codec, &chip->bus) { + if (codec->forced_resume && pm_runtime_suspended(hda_codec_dev(codec))) + pm_request_resume(hda_codec_dev(codec)); + if (!codec->relaxed_resume && (status & (1 << codec->addr))) schedule_delayed_work(&codec->jackpoll_work, codec->jackpoll_interval); + } } /* power down again for link-controlled chips */ diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index f89506dffd5b..e4ab483db72f 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -849,6 +849,12 @@ static int alc_build_controls(struct hda_codec *codec) static void alc_pre_init(struct hda_codec *codec) { alc_fill_eapd_coef(codec); + + /* + * if controller is resumed from suspend, while codec remains in D3, codec + * needs to be woken up once or otherwise jack detection does not work + */ + codec->forced_resume = 1; } #define is_s3_resume(codec) \ -- 2.28.0

3 5

[PATCH] ASoC: mchp-spdiftx: remove 'TX' from playback stream name
by Codrin Ciubotariu 09 Oct '20

09 Oct '20

Do not include the 'TX' in the stream name since it's obvious for playback. Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu(a)microchip.com> --- sound/soc/atmel/mchp-spdiftx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/atmel/mchp-spdiftx.c b/sound/soc/atmel/mchp-spdiftx.c index 36c23eb3a5ad..82c1eecd2528 100644 --- a/sound/soc/atmel/mchp-spdiftx.c +++ b/sound/soc/atmel/mchp-spdiftx.c @@ -744,7 +744,7 @@ static struct snd_soc_dai_driver mchp_spdiftx_dai = { .probe = mchp_spdiftx_dai_probe, .remove = mchp_spdiftx_dai_remove, .playback = { - .stream_name = "S/PDIF TX Playback", + .stream_name = "S/PDIF Playback", .channels_min = 1, .channels_max = 2, .rates = MCHP_SPDIFTX_RATES, -- 2.25.1

2 1

[PATCH] ALSA: hda/i915 - fix list corruption with concurrent probes
by Kai Vehmanen 09 Oct '20

09 Oct '20

From: Takashi Iwai <tiwai(a)suse.de> Current hdac_i915 uses a static completion instance to wait for i915 driver to complete the component bind. This design is not safe if multiple HDA controllers are active and communicating with different i915 instances, and can lead to list corruption and failed audio driver probe. Fix the design by moving completion mechanism to common acomp code and remove the related code from hdac_i915. Co-developed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- include/drm/drm_audio_component.h | 4 ++++ sound/hda/hdac_component.c | 3 +++ sound/hda/hdac_i915.c | 23 +++-------------------- 3 files changed, 10 insertions(+), 20 deletions(-) diff --git a/include/drm/drm_audio_component.h b/include/drm/drm_audio_component.h index a45f93487039..0d36bfd1a4cd 100644 --- a/include/drm/drm_audio_component.h +++ b/include/drm/drm_audio_component.h @@ -117,6 +117,10 @@ struct drm_audio_component { * @audio_ops: Ops implemented by hda driver, called by DRM driver */ const struct drm_audio_component_audio_ops *audio_ops; + /** + * @master_bind_complete: completion held during component master binding + */ + struct completion master_bind_complete; }; #endif /* _DRM_AUDIO_COMPONENT_H_ */ diff --git a/sound/hda/hdac_component.c b/sound/hda/hdac_component.c index 89126c6fd216..bb37e7e0bd79 100644 --- a/sound/hda/hdac_component.c +++ b/sound/hda/hdac_component.c @@ -210,12 +210,14 @@ static int hdac_component_master_bind(struct device *dev) goto module_put; } + complete_all(&acomp->master_bind_complete); return 0; module_put: module_put(acomp->ops->owner); out_unbind: component_unbind_all(dev, acomp); + complete_all(&acomp->master_bind_complete); return ret; } @@ -296,6 +298,7 @@ int snd_hdac_acomp_init(struct hdac_bus *bus, if (!acomp) return -ENOMEM; acomp->audio_ops = aops; + init_completion(&acomp->master_bind_complete); bus->audio_component = acomp; devres_add(dev, acomp); diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index 5f0a1aa6ad84..454474ac5716 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -11,8 +11,6 @@ #include <sound/hda_i915.h> #include <sound/hda_register.h> -static struct completion bind_complete; - #define IS_HSW_CONTROLLER(pci) (((pci)->device == 0x0a0c) || \ ((pci)->device == 0x0c0c) || \ ((pci)->device == 0x0d0c) || \ @@ -130,19 +128,6 @@ static bool i915_gfx_present(void) return pci_dev_present(ids); } -static int i915_master_bind(struct device *dev, - struct drm_audio_component *acomp) -{ - complete_all(&bind_complete); - /* clear audio_ops here as it was needed only for completion call */ - acomp->audio_ops = NULL; - return 0; -} - -static const struct drm_audio_component_audio_ops i915_init_ops = { - .master_bind = i915_master_bind -}; - /** * snd_hdac_i915_init - Initialize i915 audio component * @bus: HDA core bus @@ -163,9 +148,7 @@ int snd_hdac_i915_init(struct hdac_bus *bus) if (!i915_gfx_present()) return -ENODEV; - init_completion(&bind_complete); - - err = snd_hdac_acomp_init(bus, &i915_init_ops, + err = snd_hdac_acomp_init(bus, NULL, i915_component_master_match, sizeof(struct i915_audio_component) - sizeof(*acomp)); if (err < 0) @@ -177,8 +160,8 @@ int snd_hdac_i915_init(struct hdac_bus *bus) if (!IS_ENABLED(CONFIG_MODULES) || !request_module("i915")) { /* 60s timeout */ - wait_for_completion_timeout(&bind_complete, - msecs_to_jiffies(60 * 1000)); + wait_for_completion_timeout(&acomp->master_bind_complete, + msecs_to_jiffies(60 * 1000)); } } if (!acomp->ops) { -- 2.28.0

2 1

Question about buildroot vs aplay/arecord with -d
by Kuninori Morimoto 09 Oct '20

09 Oct '20

Hi ALSA ML I'm now using buildroot, and want to use aplay/arecord in the same time with -d option. This works for me aplay -d 3 xxx And this works for me, too arecord -d 3 yyy But, this doesn't work, and system will hung up aplay -d 3 xxx & arecord -d 3 yyy Sometimes it will indicates this message rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: 0-....: (1 GPs behind) idle=496/0/0x1 softirq=228/228 fqs=2172 (detected by 1, t=6502 jiffies, g=-103, q=17) Task dump for CPU 0: task:swapper/0 state:R running task stack: 0 pid: 0 ppid: 0 flags:0x0000002a Call trace: __switch_to+0x144/0x1a0 init_task+0x0/0x1780 ... Do you know why this happen ? Thank you for your help !! Best regards --- Kuninori Morimoto

1 0

[PATCH][next] ASoC: mchp-spdifrx: fix spelling mistake "overrrun" -> "overrun"
by Colin King 09 Oct '20

09 Oct '20

From: Colin Ian King <colin.king(a)canonical.com> There is a spelling mistake in a dev_warn message. Fix it. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/atmel/mchp-spdifrx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/atmel/mchp-spdifrx.c b/sound/soc/atmel/mchp-spdifrx.c index 726e4951d9a5..e6ded6f8453f 100644 --- a/sound/soc/atmel/mchp-spdifrx.c +++ b/sound/soc/atmel/mchp-spdifrx.c @@ -338,7 +338,7 @@ static irqreturn_t mchp_spdif_interrupt(int irq, void *dev_id) } if (pending & SPDIFRX_IR_OVERRUN) { - dev_warn(dev->dev, "Overrrun detected\n"); + dev_warn(dev->dev, "Overrun detected\n"); ret = IRQ_HANDLED; } -- 2.27.0

3 2

[PATCH 0/2] ASoC: stm32: dfsdm: change rate limits
by Olivier Moysan 09 Oct '20

09 Oct '20

Widening of the supported rate range in the STM32 DFSDM driver. The rates were previously limited to 8kHz, 16kHz and 32kHz. Allow rate capture in the whole range 8kHz-48kHz as there is no hardware limitation to support it. Actual sample resolution is dependent on audio rate and DFSDM configuration. Add a trace to allow simple check of sample resolution. Olivier Moysan (2): ASoC: stm32: dfsdm: change rate limits ASoC: stm32: dfsdm: add actual resolution trace drivers/iio/adc/stm32-dfsdm-adc.c | 4 ++++ drivers/iio/adc/stm32-dfsdm.h | 2 ++ sound/soc/stm/stm32_adfsdm.c | 8 +++----- 3 files changed, 9 insertions(+), 5 deletions(-) -- 2.17.1

2 3

[PATCH v2 1/2] dt-bindings: tas2764: Add the TAS2764 binding doc
by Dan Murphy 09 Oct '20

09 Oct '20

Add the binding for the TAS2764 Smart Amplifier. Signed-off-by: Dan Murphy <dmurphy(a)ti.com> --- .../devicetree/bindings/sound/tas2764.yaml | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tas2764.yaml diff --git a/Documentation/devicetree/bindings/sound/tas2764.yaml b/Documentation/devicetree/bindings/sound/tas2764.yaml new file mode 100644 index 000000000000..d2c90c82b13f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tas2764.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/tas2764.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Texas Instruments TAS2764 Smart PA + +maintainers: + - Dan Murphy <dmurphy(a)ti.com> + +description: | + The TAS2764 is a mono, digital input Class-D audio amplifier optimized for + efficiently driving high peak power into small loudspeakers. + Integrated speaker voltage and current sense provides for + real time monitoring of loudspeaker behavior. + +properties: + compatible: + enum: + - ti,tas2764 + + reg: + maxItems: 1 + description: | + I2C address of the device can be between 0x38 to 0x45. + + reset-gpios: + description: GPIO used to reset the device. + + shutdown-gpios: + description: GPIO used to control the state of the device. + + interrupts: + maxItems: 1 + + ti,imon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX current sense time slot. + + ti,vmon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX voltage sense time slot. + + '#sound-dai-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + codec: codec@38 { + compatible = "ti,tas2764"; + reg = <0x38>; + #sound-dai-cells = <1>; + interrupt-parent = <&gpio1>; + interrupts = <14>; + reset-gpio = <&gpio1 15 0>; + shutdown-gpios = <&gpio1 15 0>; + ti,imon-slot-no = <0>; + ti,vmon-slot-no = <2>; + }; + }; + +... -- 2.28.0.585.ge1cfff676549

3 3

[PATCH v3 1/2] dt-bindings: tas2764: Add the TAS2764 binding doc
by Dan Murphy 09 Oct '20

09 Oct '20

Add the binding for the TAS2764 Smart Amplifier. Signed-off-by: Dan Murphy <dmurphy(a)ti.com> --- .../devicetree/bindings/sound/tas2764.yaml | 76 +++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tas2764.yaml diff --git a/Documentation/devicetree/bindings/sound/tas2764.yaml b/Documentation/devicetree/bindings/sound/tas2764.yaml new file mode 100644 index 000000000000..5bf8c76ecda1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tas2764.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/tas2764.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Texas Instruments TAS2764 Smart PA + +maintainers: + - Dan Murphy <dmurphy(a)ti.com> + +description: | + The TAS2764 is a mono, digital input Class-D audio amplifier optimized for + efficiently driving high peak power into small loudspeakers. + Integrated speaker voltage and current sense provides for + real time monitoring of loudspeaker behavior. + +properties: + compatible: + enum: + - ti,tas2764 + + reg: + maxItems: 1 + description: | + I2C address of the device can be between 0x38 to 0x45. + + reset-gpios: + maxItems: 1 + description: GPIO used to reset the device. + + shutdown-gpios: + maxItems: 1 + description: GPIO used to control the state of the device. + + interrupts: + maxItems: 1 + + ti,imon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX current sense time slot. + + ti,vmon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX voltage sense time slot. + + '#sound-dai-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + codec: codec@38 { + compatible = "ti,tas2764"; + reg = <0x38>; + #sound-dai-cells = <1>; + interrupt-parent = <&gpio1>; + interrupts = <14>; + reset-gpios = <&gpio1 15 0>; + shutdown-gpios = <&gpio1 15 0>; + ti,imon-slot-no = <0>; + ti,vmon-slot-no = <2>; + }; + }; + +... -- 2.28.0.585.ge1cfff676549

2 2

[PATCH 1/2] ASoC: Intel: catpt: Fix compilation when CONFIG_MODULES is disabled
by Cezary Rojewski 09 Oct '20

09 Oct '20

module_is_live() is available only when CONFIG_MODULES is enabled. Replace its usage with try_module_get() which is present regardless of said config's status. Fixes: 7a10b66a5df9 ("ASoC: Intel: catpt: Device driver lifecycle") Reported-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- sound/soc/intel/catpt/device.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/catpt/device.c b/sound/soc/intel/catpt/device.c index 390ffb203de0..a70179959795 100644 --- a/sound/soc/intel/catpt/device.c +++ b/sound/soc/intel/catpt/device.c @@ -81,10 +81,11 @@ static int __maybe_unused catpt_resume(struct device *dev) if (ret) return ret; - if (!module_is_live(dev->driver->owner)) { + if (!try_module_get(dev->driver->owner)) { dev_info(dev, "module unloading, skipping fw boot\n"); return 0; } + module_put(dev->driver->owner); ret = catpt_boot_firmware(cdev, true); if (ret) { @@ -107,10 +108,12 @@ static int __maybe_unused catpt_resume(struct device *dev) static int __maybe_unused catpt_runtime_suspend(struct device *dev) { - if (!module_is_live(dev->driver->owner)) { + if (!try_module_get(dev->driver->owner)) { dev_info(dev, "module unloading, skipping suspend\n"); return 0; } + module_put(dev->driver->owner); + return catpt_suspend(dev); } -- 2.17.1

3 4

[PATCH] ASoC: ti: davinci-mcasp: Use &pdev->dev for early dev_warn
by Peter Ujfalusi 09 Oct '20

09 Oct '20

At this point mcasp->dev is not initialized and we would have NULL pointer dereference if we would have failed to get the mem memory resource by name. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/ti/davinci-mcasp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c index 3ffdd0f6292a..a6b72ad53b43 100644 --- a/sound/soc/ti/davinci-mcasp.c +++ b/sound/soc/ti/davinci-mcasp.c @@ -2155,7 +2155,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev) mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpu"); if (!mem) { - dev_warn(mcasp->dev, + dev_warn(&pdev->dev, "\"mpu\" mem resource not found, using index 0\n"); mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!mem) { -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2 1

(Optional?) DMA vs. PIO
by Andy Shevchenko 08 Oct '20

08 Oct '20

Hi! During internal review of one patch I have been puzzled with the following code and Pierre suggested to ask mailing list for help. My main concern is what was the idea behind? Does it mean we support optional DMA in such case? If now, why not to return an error code directly? ---8<---8<---8<--- > Why ASoC core has the following code in the first place: > > 387 chan = dma_request_chan(dev, name); > 388 if (IS_ERR(chan)) { > 389 if (PTR_ERR(chan) == -EPROBE_DEFER) > 390 return -EPROBE_DEFER; > 391 pcm->chan[i] = NULL; > 392 } else { > 393 pcm->chan[i] = chan; > 394 } > > (note lines 389-391). > If PIO fallback is not okay, why not to return an error there? no idea, the code has been this way since 2013 (5eda87b890f867b098e5566b5543642851e8b9c3) It's worth asking the question on the mailing list, I don't know if this is a bug or a feature. -- With Best Regards, Andy Shevchenko

4 3

[PATCH] ALSA: hda/realtek - The front Mic on a HP machine doesn't work
by Jeremy Szu 08 Oct '20

08 Oct '20

On a HP ZCentral, the front Mic could not be detected. The codec of the HP ZCentrol is alc671 and it needs to override the pin configuration to enable the headset mic. Signed-off-by: Jeremy Szu <jeremy.szu(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index d4f17b465892..add79ed08bdb 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -9622,6 +9622,7 @@ static const struct snd_pci_quirk alc662_fixup_tbl[] = { SND_PCI_QUIRK(0x1028, 0x0698, "Dell", ALC668_FIXUP_DELL_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x069f, "Dell", ALC668_FIXUP_DELL_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800), + SND_PCI_QUIRK(0x103c, 0x873e, "HP", ALC671_FIXUP_HP_HEADSET_MIC2), SND_PCI_QUIRK(0x1043, 0x1080, "Asus UX501VW", ALC668_FIXUP_HEADSET_MODE), SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", ALC662_FIXUP_ASUS_Nx50), SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX", ALC662_FIXUP_BASS_1A), -- 2.28.0

2 1

[PATCH 4/6] ALSA: hdspm: Fix typo arbitary
by Naoki Hayama 08 Oct '20

08 Oct '20

Fix comment typo. s/arbitary/arbitrary/ Signed-off-by: Naoki Hayama <naoki.hayama(a)lineo.co.jp> --- sound/pci/rme9652/hdspm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/rme9652/hdspm.c b/sound/pci/rme9652/hdspm.c index 572350aaf18d..a808b445afd8 100644 --- a/sound/pci/rme9652/hdspm.c +++ b/sound/pci/rme9652/hdspm.c @@ -1217,7 +1217,7 @@ static int snd_hdspm_use_is_exclusive(struct hdspm *hdspm) return ret; } -/* round arbitary sample rates to commonly known rates */ +/* round arbitrary sample rates to commonly known rates */ static int hdspm_round_frequency(int rate) { if (rate < 38050) -- 2.17.1

2 1

[PATCH 0/6] spelling: Fix typo related to "arbitrary"
by Naoki Hayama 08 Oct '20

08 Oct '20

I found some typos related to "arbitrary". s/abitrary/arbitrary/ s/arbitary/arbitrary/ This series fixes them. These typos have been reported in the past in other codes, but correction 'abitrary||arbitrary' wasn't added to scripts/spelling.txt. Therefore, PATCH #6 adds it to spelling.txt. Naoki Hayama (6): net: tlan: Fix typo abitrary dt-bindings: pinctrl: qcom: Fix typo abitrary dt-bindings: pinctrl: sirf: Fix typo abitrary ALSA: hdspm: Fix typo arbitary drm/etnaviv: Fix typo arbitary scripts/spelling.txt: Add arbitrary correction Documentation/devicetree/bindings/pinctrl/pinctrl-atlas7.txt | 2 +- .../devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt | 2 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +- drivers/net/ethernet/ti/tlan.c | 2 +- scripts/spelling.txt | 1 + sound/pci/rme9652/hdspm.c | 2 +- 6 files changed, 6 insertions(+), 5 deletions(-) -- 2.17.1

1 0

[PATCH 0/6] Ancillary bus implementation and SOF multi-client support
by Dave Ertman 07 Oct '20

07 Oct '20

Brief history of Ancillary Bus ============================== The ancillary bus code was originally submitted upstream as virtual bus, and was submitted through the netdev tree.  This process generated up to v4.  This discussion can be found here: https://lore.kernel.org/netdev/0200520070227.3392100-2-jeffrey.t.kirsher@in… At this point, GregKH requested that we take the review and revision process to an internal mailing list and garner the buy-in of a respected kernel contributor. The ancillary bus (then known as virtual bus) was originally submitted along with implementation code for the ice driver and irdma drive, causing the complication of also having dependencies in the rdma tree. This new submission is utilizing an ancillary bus consumer in only the sound driver tree to create the initial implementation and a single user. Since implementation work has started on this patch set, there have been multiple inquiries about the time frame of its completion. It appears that there will be numerous consumers of this functionality. The process of internal review and implementation using the sound drivers generated 19 internal versions.  The changes, including the name change from virtual bus to ancillary bus, from these versions can be summarized as the following: - Fixed compilation and checkpatch errors - Improved documentation to address the motivation for virtual bus. - Renamed virtual bus to ancillary bus - increased maximum device name size - Correct order in Kconfig and Makefile - removed the mid-layer adev->release layer for device unregister - pushed adev->id management to parent driver - all error paths out of ancillary_device_register return error code - all error paths out of ancillary_device_register use put_device - added adev->name element - modname in register cannot be NULL - added KBUILD_MODNAME as prefix for match_name - push adev->id responsibility to registering driver - uevent now parses adev->dev name - match_id function now parses adev->dev name - changed drivers probe function to also take an ancillary_device_id param - split ancillary_device_register into device_initialize and device_add - adjusted what is done in device_initialize and device_add - change adev to ancildev and adrv to ancildrv - change adev to ancildev in documentation This submission is the first time that this patch set will be sent to the alsa-devel mailing list, so it is currently being submitted as version 1. ========================== Introduces the ancillary bus implementation along with the example usage in the Sound Open Firmware(SOF) audio driver. In some subsystems, the functionality of the core device (PCI/ACPI/other) may be too complex for a single device to be managed as a monolithic block or a part of the functionality might need to be exposed to a different subsystem. Splitting the functionality into smaller orthogonal devices makes it easier to manage data, power management and domain-specific communication with the hardware. Also, common ancillary_device functionality across primary devices can be handled by a common ancillary_device. A key requirement for such a split is that there is no dependency on a physical bus, device, register accesses or regmap support. These individual devices split from the core cannot live on the platform bus as they are not physical devices that are controlled by DT/ACPI. The same argument applies for not using MFD in this scenario as it relies on individual function devices being physical devices that are DT enumerated. An example for this kind of requirement is the audio subsystem where a single IP handles multiple entities such as HDMI, Soundwire, local devices such as mics/speakers etc. The split for the core's functionality can be arbitrary or be defined by the DSP firmware topology and include hooks for test/debug. This allows for the audio core device to be minimal and tightly coupled with handling the hardware-specific logic and communication. The ancillary bus is intended to be minimal, generic and avoid domain-specific assumptions. Each ancillary bus device represents a part of its parent functionality. The generic behavior can be extended and specialized as needed by encapsulating an ancillary bus device within other domain-specific structures and the use of .ops callbacks. The SOF driver adopts the ancillary bus for implementing the multi-client support. A client in the context of the SOF driver represents a part of the core device's functionality. It is not a physical device but rather an ancillary device that needs to communicate with the DSP via IPCs. With multi-client support,the sound card can be separated into multiple orthogonal ancillary devices for local devices (mic/speakers etc), HDMI, sensing, probes, debug etc. In this series, we demonstrate the usage of the ancillary bus with the help of the IPC test client which is used for testing the serialization of IPCs when multiple clients talk to the DSP at the same time. Dave Ertman (1): Add ancillary bus support Fred Oh (1): ASoC: SOF: debug: Remove IPC flood test support in SOF core Ranjani Sridharan (4): ASoC: SOF: Introduce descriptors for SOF client ASoC: SOF: Create client driver for IPC test ASoC: SOF: ops: Add ops for client registration ASoC: SOF: Intel: Define ops for client registration Documentation/driver-api/ancillary_bus.rst | 230 +++++++++++++++ Documentation/driver-api/index.rst | 1 + drivers/bus/Kconfig | 3 + drivers/bus/Makefile | 3 + drivers/bus/ancillary.c | 191 +++++++++++++ include/linux/ancillary_bus.h | 58 ++++ include/linux/mod_devicetable.h | 8 + scripts/mod/devicetable-offsets.c | 3 + scripts/mod/file2alias.c | 8 + sound/soc/sof/Kconfig | 29 +- sound/soc/sof/Makefile | 7 + sound/soc/sof/core.c | 12 + sound/soc/sof/debug.c | 230 --------------- sound/soc/sof/intel/Kconfig | 9 + sound/soc/sof/intel/Makefile | 3 + sound/soc/sof/intel/apl.c | 18 ++ sound/soc/sof/intel/bdw.c | 18 ++ sound/soc/sof/intel/byt.c | 22 ++ sound/soc/sof/intel/cnl.c | 18 ++ sound/soc/sof/intel/intel-client.c | 49 ++++ sound/soc/sof/intel/intel-client.h | 26 ++ sound/soc/sof/ops.h | 14 + sound/soc/sof/sof-client.c | 117 ++++++++ sound/soc/sof/sof-client.h | 65 +++++ sound/soc/sof/sof-ipc-test-client.c | 314 +++++++++++++++++++++ sound/soc/sof/sof-priv.h | 16 +- 26 files changed, 1233 insertions(+), 239 deletions(-) create mode 100644 Documentation/driver-api/ancillary_bus.rst create mode 100644 drivers/bus/ancillary.c create mode 100644 include/linux/ancillary_bus.h create mode 100644 sound/soc/sof/intel/intel-client.c create mode 100644 sound/soc/sof/intel/intel-client.h create mode 100644 sound/soc/sof/sof-client.c create mode 100644 sound/soc/sof/sof-client.h create mode 100644 sound/soc/sof/sof-ipc-test-client.c -- 2.26.2

12 98

[PATCH] ALSA: bebob: potential info leak in hwdep_read()
by Dan Carpenter 07 Oct '20

07 Oct '20

The "count" variable needs to be capped on every path so that we don't copy too much information to the user. Fixes: 618eabeae711 ("ALSA: bebob: Add hwdep interface") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- sound/firewire/bebob/bebob_hwdep.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/firewire/bebob/bebob_hwdep.c b/sound/firewire/bebob/bebob_hwdep.c index 45b740f44c45..c362eb38ab90 100644 --- a/sound/firewire/bebob/bebob_hwdep.c +++ b/sound/firewire/bebob/bebob_hwdep.c @@ -36,12 +36,11 @@ hwdep_read(struct snd_hwdep *hwdep, char __user *buf, long count, } memset(&event, 0, sizeof(event)); + count = min_t(long, count, sizeof(event.lock_status)); if (bebob->dev_lock_changed) { event.lock_status.type = SNDRV_FIREWIRE_EVENT_LOCK_STATUS; event.lock_status.status = (bebob->dev_lock_count > 0); bebob->dev_lock_changed = false; - - count = min_t(long, count, sizeof(event.lock_status)); } spin_unlock_irq(&bebob->lock); -- 2.28.0

3 3

[PATCH] ALSA: hda/realtek: Enable audio jacks of ASUS D700SA with ALC887
by Jian-Hong Pan 07 Oct '20

07 Oct '20

The ASUS D700SA desktop's audio (1043:2390) with ALC887 cannot detect the headset microphone and another headphone jack until ALC887_FIXUP_ASUS_HMIC and ALC887_FIXUP_ASUS_AUDIO quirks are applied. The NID 0x15 maps as the headset microphone and NID 0x19 maps as another headphone jack. Also need the function like alc887_fixup_asus_jack to enable the audio jacks. Signed-off-by: Jian-Hong Pan <jhp(a)endlessos.org> Signed-off-by: Kailang Yang <kailang(a)realtek.com> --- sound/pci/hda/patch_realtek.c | 41 +++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index d4f17b465892..8d0928bdc9ff 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -1929,6 +1929,8 @@ enum { ALC1220_FIXUP_CLEVO_P950, ALC1220_FIXUP_CLEVO_PB51ED, ALC1220_FIXUP_CLEVO_PB51ED_PINS, + ALC887_FIXUP_ASUS_AUDIO, + ALC887_FIXUP_ASUS_HMIC, }; static void alc889_fixup_coef(struct hda_codec *codec, @@ -2141,6 +2143,30 @@ static void alc1220_fixup_clevo_pb51ed(struct hda_codec *codec, alc_fixup_headset_mode_no_hp_mic(codec, fix, action); } +static void alc887_asus_hp_automute_hook(struct hda_codec *codec, + struct hda_jack_callback *jack) +{ + struct alc_spec *spec = codec->spec; + int vref; + + snd_hda_gen_hp_automute(codec, jack); + + vref = spec->gen.hp_jack_present ? 0xc4 : 0xc0; + snd_hda_codec_write(codec, 0x19, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, + vref); +} + +static void alc887_fixup_asus_jack(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + if (action != HDA_FIXUP_ACT_PROBE) + return; + snd_hda_codec_write(codec, 0x1b, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, + 0xc0); + spec->gen.hp_automute_hook = alc887_asus_hp_automute_hook; +} + static const struct hda_fixup alc882_fixups[] = { [ALC882_FIXUP_ABIT_AW9D_MAX] = { .type = HDA_FIXUP_PINS, @@ -2398,6 +2424,20 @@ static const struct hda_fixup alc882_fixups[] = { .chained = true, .chain_id = ALC1220_FIXUP_CLEVO_PB51ED, }, + [ALC887_FIXUP_ASUS_AUDIO] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { + { 0x15, 0x02a14150 }, /* use as headset mic, without its own jack detect */ + { 0x19, 0x22219420 }, + {} + }, + }, + [ALC887_FIXUP_ASUS_HMIC] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc887_fixup_asus_jack, + .chained = true, + .chain_id = ALC887_FIXUP_ASUS_AUDIO, + }, }; static const struct snd_pci_quirk alc882_fixup_tbl[] = { @@ -2431,6 +2471,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x13c2, "Asus A7M", ALC882_FIXUP_EAPD), SND_PCI_QUIRK(0x1043, 0x1873, "ASUS W90V", ALC882_FIXUP_ASUS_W90V), SND_PCI_QUIRK(0x1043, 0x1971, "Asus W2JC", ALC882_FIXUP_ASUS_W2JC), + SND_PCI_QUIRK(0x1043, 0x2390, "Asus D700SA", ALC887_FIXUP_ASUS_HMIC), SND_PCI_QUIRK(0x1043, 0x835f, "Asus Eee 1601", ALC888_FIXUP_EEE1601), SND_PCI_QUIRK(0x1043, 0x84bc, "ASUS ET2700", ALC887_FIXUP_ASUS_BASS), SND_PCI_QUIRK(0x1043, 0x8691, "ASUS ROG Ranger VIII", ALC882_FIXUP_GPIO3), -- 2.28.0

2 3

[PATCH] ALSA: usb-audio: ignore broken processing/extension unit
by tom.ty89＠gmail.com 07 Oct '20

07 Oct '20

From: Tom Yan <tom.ty89(a)gmail.com> Some devices have broken extension unit where getting current value doesn't work. Attempt that once when creating mixer control for it. If it fails, just ignore it, so that it won't cripple the device entirely (and/or make the error floods). Signed-off-by: Tom Yan <tom.ty89(a)gmail.com> --- sound/usb/mixer.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index eab0fd4fd7c3..e0b7174c1043 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -2367,7 +2367,7 @@ static int build_audio_procunit(struct mixer_build *state, int unitid, int num_ins; struct usb_mixer_elem_info *cval; struct snd_kcontrol *kctl; - int i, err, nameid, type, len; + int i, err, nameid, type, len, val; const struct procunit_info *info; const struct procunit_value_info *valinfo; const struct usbmix_name_map *map; @@ -2470,6 +2470,12 @@ static int build_audio_procunit(struct mixer_build *state, int unitid, break; } + err = get_cur_ctl_value(cval, cval->control << 8, &val); + if (err < 0) { + usb_mixer_elem_info_free(cval); + return -EINVAL; + } + kctl = snd_ctl_new1(&mixer_procunit_ctl, cval); if (!kctl) { usb_mixer_elem_info_free(cval); -- 2.28.0

3 2

[PATCH] ASoC: omap-mcbsp: Fix use of uninitialised pointer
by Alex Dewar 07 Oct '20

07 Oct '20

Commit 9c34d023dc35 ("ASoC: omap-mcbsp: Re-arrange files for core McBSP and Sidetone function split"), in rearranging various files, also replaced calls to platform_get_resource_by_name() + devm_ioremap_resource() with a single call to devm_platform_ioremap_resource_byname(). However, the struct resource is needed as we access its members so at present a null pointer is dereferenced. Fix by doing things the old way. Addresses-Coverity-ID: 1497530 ("Memory - illegal accesses") Fixes: 9c34d023dc35 ("ASoC: omap-mcbsp: Re-arrange files for core McBSP and Sidetone function split") Signed-off-by: Alex Dewar <alex.dewar90(a)gmail.com> --- sound/soc/ti/omap-mcbsp.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/ti/omap-mcbsp.c b/sound/soc/ti/omap-mcbsp.c index 186cea91076f..6025b30bbe77 100644 --- a/sound/soc/ti/omap-mcbsp.c +++ b/sound/soc/ti/omap-mcbsp.c @@ -620,7 +620,11 @@ static int omap_mcbsp_init(struct platform_device *pdev) spin_lock_init(&mcbsp->lock); mcbsp->free = true; - mcbsp->io_base = devm_platform_ioremap_resource_byname(pdev, "mpu"); + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpu"); + if (!res) + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + + mcbsp->io_base = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(mcbsp->io_base)) return PTR_ERR(mcbsp->io_base); -- 2.28.0

3 2

[PATCH v10 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
by Srinivasa Rao Mandadapu 07 Oct '20

07 Oct '20

These patches are to support audio over DP port on Qualcomm's SC7180 LPASS Asoc. It includes machine driver, cpu driver, platform driver updates for HDMI path support, device tree documention, lpass variant structure optimization and configuration changes. These patches depends on the DP patch series https://patchwork.kernel.org/project/dri-devel/list/?series=332029 https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 changes since V9: -- Removed unused structures lpass_hdmi.h changes since V8: -- Removed redundant structure wrapper for reg map field memebrs -- Updated lpass_hdmi_regmap_volatile API with appropriate registers as true and others as false. changes since V7: -- Fixed typo errors -- Created Separate patch for buffer size change changes since V6: -- Removed compile time define flag, which used for enabling HDMI code, based on corresponding config param is included. -- Updated reg map alloc API with reg map bulk API. -- Removed unnecessary line splits changes since V5: -- Removed unused struct regmap *map in lpass_platform_alloc_hdmidmactl_fields. -- DMA alloc and free API signature change in lpass-apq8016.c, lpass-ipq806x.c -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro Changes Since v4: -- Updated with single compatible node for both I2S and HDMI. Changes Since v3: -- Removed id in lpass variant structure and used snd_soc_dai_driver id. Changes Since v2: -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in lpass-platform.c increased. Changes Since v1: -- Commit messages are updated -- Addressed Rob Herring review comments V Sujith Kumar Reddy (8): ASoC: Add sc7180-lpass binding header hdmi define ASoC: dt-bindings: Add dt binding for lpass hdmi Asoc:qcom:lpass-cpu:Update dts property read API Asoc: qcom: lpass:Update lpaif_dmactl members order ASoC: qcom: Add support for lpass hdmi driver Asoc: qcom: lpass-platform : Increase buffer size ASoC: qcom: sc7180: Add support for audio over DP .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 +++- include/dt-bindings/sound/sc7180-lpass.h | 1 + sound/soc/qcom/Kconfig | 5 + sound/soc/qcom/Makefile | 2 + sound/soc/qcom/lpass-apq8016.c | 4 +- sound/soc/qcom/lpass-cpu.c | 53 ++- sound/soc/qcom/lpass-hdmi.c | 468 +++++++++++++++++++++ sound/soc/qcom/lpass-hdmi.h | 106 +++++ sound/soc/qcom/lpass-ipq806x.c | 4 +- sound/soc/qcom/lpass-lpaif-reg.h | 52 ++- sound/soc/qcom/lpass-platform.c | 403 ++++++++++++++---- sound/soc/qcom/lpass-sc7180.c | 116 ++++- sound/soc/qcom/lpass.h | 119 +++++- 13 files changed, 1262 insertions(+), 145 deletions(-) create mode 100644 sound/soc/qcom/lpass-hdmi.c create mode 100644 sound/soc/qcom/lpass-hdmi.h -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

2 9

Fwd: [alsa-devel] trying to get an eleven rack to work
by Jerzy Dubin 07 Oct '20

07 Oct '20

Hello Clemens, any news in this topics : https://mailman.alsa-project.org/pipermail/alsa-devel/2012-April/050944.html https://www.alsa-project.org/pipermail/alsa-devel/2012-March/050649.html I tried to get it work and added in sound/usb/quirks-table.h |USB_DEVICE_VENDOR_SPEC(0x0dba, 0xb011), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .vendor_name = "Digidesign", .product_name = "Eleven Rack", .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = & (const struct snd_usb_audio_quirk[]) { { .ifnum = 1, .type = QUIRK_AUDIO_STANDARD_MIXER }, { .ifnum = 3, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 4, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = -1 } } } } Then there was problem with sample rates(|||unable to retrieve number of sample rates| ) so i modified |sound/usb/format.c (i have checked sample rates on device): |if (ret < 0) { switch (chip->usb_id) { case USB_ID(0x0dba, 0xb011): /* Eleven Rack */ dev_info(&dev->dev, "%s(): Eleven Rack: unable to retrieve number of sample rates. Set it to default value (clock %d).\n",__func__, clock); fp->nr_rates = 1; fp->rate_min = 44100; fp->rate_max = 44100; fp->rates = SNDRV_PCM_RATE_44100; fp->rate_table = kmalloc(sizeof(int), GFP_KERNEL); if (!fp->rate_table) { ret = -ENOMEM; goto err_free; } fp->rate_table[0] = 44100; return 0; default: dev_err(&dev->dev, "%s(): unable to retrieve number of sample rates (clock %d)\n", __func__, clock); goto err; } } Now im getting : ||[ 152.114655] usb 1-4: new high-speed USB device number 6 using xhci_hcd [ 152.268388] usb 1-4: New USB device found, idVendor=0dba, idProduct=b011, bcdDevice=20.01 [ 152.268393] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 152.268395] usb 1-4: Product: Eleven Rack [ 152.268397] usb 1-4: Manufacturer: Digidesign [ 152.311112] usb 1-4: parse_audio_format_rates_v2v3(): Eleven Rack: unable to retrieve number of sample rates. Set it to default value (clock 129). [ 152.312918] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.316184] usbcore: registered new interface driver snd-usb-audio [ 152.364920] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.366262] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.366991] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.367432] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.368070] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.371067] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.372155] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.372496] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.373180] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.373894] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.376748] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.377498] usb 1-4: 4:1: cannot set enable PITCH (v2) [ 152.378690] usb 1-4: 4:1: cannot set enable PITCH (v2) Should i still wait for backend infrastructure ? Or there is something what i can do here ? Regards, Jurek |||||

1 0

[PATCH 1/2] ASoC: fsl: fsl_ssi: add ac97 fixed mode support
by Primoz Fiser 07 Oct '20

07 Oct '20

SSI supports "variable" and "fixed" mode of operation in AC'97 mode. Up to now, driver always configured SSI port to operate in "variable" AC'97 mode which is known to be unreliable with some CODECs, see: commit 01ca485171e3 ("ASoC: fsl_ssi: only enable proper channel slots in AC'97 mode") for more information on issues related to spurious SLOTREQ bits. But in summary, when SSI operates in AC'97 variable mode of operation, CODECs can sometimes send SLOTREQ bits for non-existent audio slots which then "stick" in SSI and completely break audio output. Contrary when operating SSI in AC'97 fixed mode, described issues were completely gone! Thus add support for operating SSI in AC'97 Fixed Mode of operation which provides better audio reliability when compared to AC'97 Variable Mode with some CODECs. Signed-off-by: Primoz Fiser <primoz.fiser(a)norik.com> --- sound/soc/fsl/fsl_ssi.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 404be27c15fe..3b89785f6de8 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -243,6 +243,7 @@ struct fsl_ssi_soc_data { * @dma_maxburst: Max number of words to transfer in one go. So far, * this is always the same as fifo_watermark. * @ac97_reg_lock: Mutex lock to serialize AC97 register access operations + * @ac97_fixed_mode: SSI in AC97 fixed mode of operation */ struct fsl_ssi { struct regmap *regs; @@ -287,6 +288,7 @@ struct fsl_ssi { u32 dma_maxburst; struct mutex ac97_reg_lock; + bool ac97_fixed_mode; }; /* @@ -616,7 +618,12 @@ static void fsl_ssi_setup_ac97(struct fsl_ssi *ssi) regmap_write(regs, REG_SSI_SRCCR, SSI_SxCCR_WL(17) | SSI_SxCCR_DC(13)); /* Enable AC97 mode and startup the SSI */ - regmap_write(regs, REG_SSI_SACNT, SSI_SACNT_AC97EN | SSI_SACNT_FV); + if (ssi->ac97_fixed_mode) { + regmap_write(regs, REG_SSI_SACNT, SSI_SACNT_AC97EN); + regmap_write(regs, REG_SSI_SATAG, 0x9800); + } else + regmap_write(regs, REG_SSI_SACNT, + SSI_SACNT_AC97EN | SSI_SACNT_FV); /* AC97 has to communicate with codec before starting a stream */ regmap_update_bits(regs, REG_SSI_SCR, @@ -1092,8 +1099,10 @@ static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd, * send valid data to slots other than normal playback slots. * * To be safe, configure SACCST right before TX starts. + * + * Above applies only when SSI operates in AC97 Variable Mode. */ - if (tx && fsl_ssi_is_ac97(ssi)) + if (tx && fsl_ssi_is_ac97(ssi) && !ssi->ac97_fixed_mode) fsl_ssi_tx_ac97_saccst_setup(ssi); fsl_ssi_config_enable(ssi, tx); break; @@ -1437,6 +1446,11 @@ static int fsl_ssi_probe_from_dt(struct fsl_ssi *ssi) ssi->synchronous = true; } + /* Check AC97 mode of operation */ + sprop = of_get_property(np, "fsl,ac97-mode", NULL); + if (sprop && !strcmp(sprop, "fixed")) + ssi->ac97_fixed_mode = true; + /* Select DMA or FIQ */ ssi->use_dma = !of_property_read_bool(np, "fsl,fiq-stream-filter"); -- 2.25.1

5 10

Re: linux-next: Tree for Oct 6 (sound/soc/intel/catpt/device.c)
by Randy Dunlap 06 Oct '20

06 Oct '20

On 10/6/20 5:12 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20201002: > on x86_64 or i386: when CONFIG_MODULES is not set/enabled: ../sound/soc/intel/catpt/device.c: In function ‘catpt_resume’: ../sound/soc/intel/catpt/device.c:84:7: error: implicit declaration of function ‘module_is_live’; did you mean ‘module_driver’? [-Werror=implicit-function-declaration] if (!module_is_live(dev->driver->owner)) { ^~~~~~~~~~~~~~ module_driver You could see commit cdb685cb9158fa67f6f4584ea39279ed7ae39253 Author: Danil Kipnis <danil.kipnis(a)cloud.ionos.com> Date: Thu May 21 20:59:09 2020 +0200 RDMA/rnbd: Fix compilation error when CONFIG_MODULES is disabled for a possible fix. -- ~Randy Reported-by: Randy Dunlap <rdunlap(a)infradead.org>

1 1

[PATCH v5 22/52] docs: get rid of :c:type explicit declarations for structs
by Mauro Carvalho Chehab 06 Oct '20

06 Oct '20

The :c:type:`foo` only works properly with structs before Sphinx 3.x. On Sphinx 3.x, structs should now be declared using the .. c:struct, and referenced via :c:struct tag. As we now have the automarkup.py macro, that automatically convert: struct foo into cross-references, let's get rid of that, solving several warnings when building docs with Sphinx 3.x. Reviewed-by: André Almeida <andrealmeid(a)collabora.com> # blk-mq.rst Reviewed-by: Takashi Iwai <tiwai(a)suse.de> # sound Reviewed-by: Mike Rapoport <rppt(a)linux.ibm.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- Documentation/block/blk-mq.rst | 8 +++---- Documentation/block/inline-encryption.rst | 8 +++---- Documentation/driver-api/fpga/fpga-bridge.rst | 4 ++-- Documentation/driver-api/fpga/fpga-mgr.rst | 4 ++-- Documentation/driver-api/fpga/fpga-region.rst | 2 +- Documentation/driver-api/iio/buffers.rst | 2 +- Documentation/driver-api/iio/core.rst | 6 ++--- Documentation/driver-api/iio/hw-consumer.rst | 2 +- .../driver-api/iio/triggered-buffers.rst | 2 +- Documentation/driver-api/iio/triggers.rst | 4 ++-- .../driver-api/media/dtv-frontend.rst | 4 ++-- Documentation/driver-api/media/mc-core.rst | 24 +++++++++---------- .../driver-api/media/v4l2-controls.rst | 2 +- Documentation/driver-api/media/v4l2-dev.rst | 8 +++---- .../driver-api/media/v4l2-device.rst | 6 ++--- Documentation/driver-api/media/v4l2-event.rst | 10 ++++---- Documentation/driver-api/media/v4l2-fh.rst | 16 ++++++------- .../driver-api/media/v4l2-subdev.rst | 2 +- Documentation/driver-api/regulator.rst | 4 ++-- Documentation/driver-api/usb/URB.rst | 2 +- Documentation/driver-api/usb/gadget.rst | 10 ++++---- Documentation/driver-api/usb/hotplug.rst | 2 +- Documentation/filesystems/fscrypt.rst | 14 +++++------ Documentation/filesystems/fsverity.rst | 2 +- Documentation/sound/designs/tracepoints.rst | 22 ++++++++--------- Documentation/sphinx/parse-headers.pl | 2 +- Documentation/vm/ksm.rst | 2 +- Documentation/vm/memory-model.rst | 6 ++--- mm/ksm.c | 2 +- mm/memblock.c | 4 ++-- 30 files changed, 93 insertions(+), 93 deletions(-) diff --git a/Documentation/block/blk-mq.rst b/Documentation/block/blk-mq.rst index 88c56afcb070..86a632af02b0 100644 --- a/Documentation/block/blk-mq.rst +++ b/Documentation/block/blk-mq.rst @@ -63,10 +63,10 @@ Software staging queues ~~~~~~~~~~~~~~~~~~~~~~~ The block IO subsystem adds requests in the software staging queues -(represented by struct :c:type:`blk_mq_ctx`) in case that they weren't sent +(represented by struct blk_mq_ctx) in case that they weren't sent directly to the driver. A request is one or more BIOs. They arrived at the -block layer through the data structure struct :c:type:`bio`. The block layer -will then build a new structure from it, the struct :c:type:`request` that will +block layer through the data structure struct bio. The block layer +will then build a new structure from it, the struct request that will be used to communicate with the device driver. Each queue has its own lock and the number of queues is defined by a per-CPU or per-node basis. @@ -102,7 +102,7 @@ hardware queue will be drained in sequence according to their mapping. Hardware dispatch queues ~~~~~~~~~~~~~~~~~~~~~~~~ -The hardware queue (represented by struct :c:type:`blk_mq_hw_ctx`) is a struct +The hardware queue (represented by struct blk_mq_hw_ctx) is a struct used by device drivers to map the device submission queues (or device DMA ring buffer), and are the last step of the block layer submission code before the low level device driver taking ownership of the request. To run this queue, the diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 354817b80887..e75151e467d3 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -52,7 +52,7 @@ Constraints and notes Design ====== -We add a :c:type:`struct bio_crypt_ctx` to :c:type:`struct bio` that can +We add a struct bio_crypt_ctx to struct bio that can represent an encryption context, because we need to be able to pass this encryption context from the upper layers (like the fs layer) to the device driver to act upon. @@ -85,7 +85,7 @@ blk-mq changes, other block layer changes and blk-crypto-fallback ================================================================= We add a pointer to a ``bi_crypt_context`` and ``keyslot`` to -:c:type:`struct request`. These will be referred to as the ``crypto fields`` +struct request. These will be referred to as the ``crypto fields`` for the request. This ``keyslot`` is the keyslot into which the ``bi_crypt_context`` has been programmed in the KSM of the ``request_queue`` that this request is being sent to. @@ -118,7 +118,7 @@ of the algorithm being used adheres to spec and functions correctly). If a ``request queue``'s inline encryption hardware claimed to support the encryption context specified with a bio, then it will not be handled by the ``blk-crypto-fallback``. We will eventually reach a point in blk-mq when a -:c:type:`struct request` needs to be allocated for that bio. At that point, +struct request needs to be allocated for that bio. At that point, blk-mq tries to program the encryption context into the ``request_queue``'s keyslot_manager, and obtain a keyslot, which it stores in its newly added ``keyslot`` field. This keyslot is released when the request is completed. @@ -188,7 +188,7 @@ keyslots supported by the hardware. The device driver also needs to tell the KSM how to actually manipulate the IE hardware in the device to do things like programming the crypto key into the IE hardware into a particular keyslot. All this is achieved through the -:c:type:`struct blk_ksm_ll_ops` field in the KSM that the device driver +struct blk_ksm_ll_ops field in the KSM that the device driver must fill up after initing the ``blk_keyslot_manager``. The KSM also handles runtime power management for the device when applicable diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst index ccd677ba7d76..198aadafd3e7 100644 --- a/Documentation/driver-api/fpga/fpga-bridge.rst +++ b/Documentation/driver-api/fpga/fpga-bridge.rst @@ -4,8 +4,8 @@ FPGA Bridge API to implement a new FPGA bridge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* struct :c:type:`fpga_bridge` — The FPGA Bridge structure -* struct :c:type:`fpga_bridge_ops` — Low level Bridge driver ops +* struct fpga_bridge — The FPGA Bridge structure +* struct fpga_bridge_ops — Low level Bridge driver ops * devm_fpga_bridge_create() — Allocate and init a bridge struct * fpga_bridge_register() — Register a bridge * fpga_bridge_unregister() — Unregister a bridge diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst index af5382af1379..22f7885b32c9 100644 --- a/Documentation/driver-api/fpga/fpga-mgr.rst +++ b/Documentation/driver-api/fpga/fpga-mgr.rst @@ -102,8 +102,8 @@ API for implementing a new FPGA Manager driver ---------------------------------------------- * ``fpga_mgr_states`` — Values for :c:member:`fpga_manager->state`. -* struct :c:type:`fpga_manager` — the FPGA manager struct -* struct :c:type:`fpga_manager_ops` — Low level FPGA manager driver ops +* struct fpga_manager — the FPGA manager struct +* struct fpga_manager_ops — Low level FPGA manager driver ops * devm_fpga_mgr_create() — Allocate and init a manager struct * fpga_mgr_register() — Register an FPGA manager * fpga_mgr_unregister() — Unregister an FPGA manager diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst index 31118a8ba218..3e52be7e2968 100644 --- a/Documentation/driver-api/fpga/fpga-region.rst +++ b/Documentation/driver-api/fpga/fpga-region.rst @@ -45,7 +45,7 @@ An example of usage can be seen in the probe function of [#f2]_. API to add a new FPGA region ---------------------------- -* struct :c:type:`fpga_region` — The FPGA region struct +* struct fpga_region — The FPGA region struct * devm_fpga_region_create() — Allocate and init a region struct * fpga_region_register() — Register an FPGA region * fpga_region_unregister() — Unregister an FPGA region diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst index dd64c9c5fb1e..3ddebddc02ca 100644 --- a/Documentation/driver-api/iio/buffers.rst +++ b/Documentation/driver-api/iio/buffers.rst @@ -2,7 +2,7 @@ Buffers ======= -* struct :c:type:`iio_buffer` — general buffer structure +* struct iio_buffer — general buffer structure * :c:func:`iio_validate_scan_mask_onehot` — Validates that exactly one channel is selected * :c:func:`iio_buffer_get` — Grab a reference to the buffer diff --git a/Documentation/driver-api/iio/core.rst b/Documentation/driver-api/iio/core.rst index 51b21e002396..715cf29482a1 100644 --- a/Documentation/driver-api/iio/core.rst +++ b/Documentation/driver-api/iio/core.rst @@ -10,7 +10,7 @@ applications manipulating sensors. The implementation can be found under Industrial I/O Devices ---------------------- -* struct :c:type:`iio_dev` - industrial I/O device +* struct iio_dev - industrial I/O device * iio_device_alloc() - allocate an :c:type:`iio_dev` from a driver * iio_device_free() - free an :c:type:`iio_dev` from a driver * iio_device_register() - register a device with the IIO subsystem @@ -66,7 +66,7 @@ Common attributes are: IIO device channels =================== -struct :c:type:`iio_chan_spec` - specification of a single channel +struct iio_chan_spec - specification of a single channel An IIO device channel is a representation of a data channel. An IIO device can have one or multiple channels. For example: @@ -77,7 +77,7 @@ have one or multiple channels. For example: * an accelerometer can have up to 3 channels representing acceleration on X, Y and Z axes. -An IIO channel is described by the struct :c:type:`iio_chan_spec`. +An IIO channel is described by the struct iio_chan_spec. A thermometer driver for the temperature sensor in the example above would have to describe its channel as follows:: diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst index 819fb9edc005..76133a3796f2 100644 --- a/Documentation/driver-api/iio/hw-consumer.rst +++ b/Documentation/driver-api/iio/hw-consumer.rst @@ -8,7 +8,7 @@ software buffer for data. The implementation can be found under :file:`drivers/iio/buffer/hw-consumer.c` -* struct :c:type:`iio_hw_consumer` — Hardware consumer structure +* struct iio_hw_consumer — Hardware consumer structure * :c:func:`iio_hw_consumer_alloc` — Allocate IIO hardware consumer * :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer * :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst index 0db12660cc90..417555dbbdf4 100644 --- a/Documentation/driver-api/iio/triggered-buffers.rst +++ b/Documentation/driver-api/iio/triggered-buffers.rst @@ -10,7 +10,7 @@ IIO triggered buffer setup * :c:func:`iio_triggered_buffer_setup` — Setup triggered buffer and pollfunc * :c:func:`iio_triggered_buffer_cleanup` — Free resources allocated by :c:func:`iio_triggered_buffer_setup` -* struct :c:type:`iio_buffer_setup_ops` — buffer setup related callbacks +* struct iio_buffer_setup_ops — buffer setup related callbacks A typical triggered buffer setup looks like this:: diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst index dfd7ba3eabde..288625e40672 100644 --- a/Documentation/driver-api/iio/triggers.rst +++ b/Documentation/driver-api/iio/triggers.rst @@ -2,7 +2,7 @@ Triggers ======== -* struct :c:type:`iio_trigger` — industrial I/O trigger device +* struct iio_trigger — industrial I/O trigger device * :c:func:`devm_iio_trigger_alloc` — Resource-managed iio_trigger_alloc * :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register iio_trigger_unregister @@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver:: IIO trigger ops =============== -* struct :c:type:`iio_trigger_ops` — operations structure for an iio_trigger. +* struct iio_trigger_ops — operations structure for an iio_trigger. Notice that a trigger has a set of operations attached: diff --git a/Documentation/driver-api/media/dtv-frontend.rst b/Documentation/driver-api/media/dtv-frontend.rst index b362109bb131..91f77fe58e83 100644 --- a/Documentation/driver-api/media/dtv-frontend.rst +++ b/Documentation/driver-api/media/dtv-frontend.rst @@ -125,7 +125,7 @@ responsible for tuning the device. It supports multiple algorithms to detect a channel, as defined at enum :c:func:`dvbfe_algo`. The algorithm to be used is obtained via ``.get_frontend_algo``. If the driver -doesn't fill its field at struct :c:type:`dvb_frontend_ops`, it will default to +doesn't fill its field at struct dvb_frontend_ops, it will default to ``DVBFE_ALGO_SW``, meaning that the dvb-core will do a zigzag when tuning, e. g. it will try first to use the specified center frequency ``f``, then, it will do ``f`` + |delta|, ``f`` - |delta|, ``f`` + 2 x |delta|, @@ -140,7 +140,7 @@ define a ``.get_frontend_algo`` function that would return ``DVBFE_ALGO_HW``. a third type (``DVBFE_ALGO_CUSTOM``), in order to allow the driver to define its own hardware-assisted algorithm. Very few hardware need to use it nowadays. Using ``DVBFE_ALGO_CUSTOM`` require to provide other - function callbacks at struct :c:type:`dvb_frontend_ops`. + function callbacks at struct dvb_frontend_ops. Attaching frontend driver to the bridge driver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/driver-api/media/mc-core.rst b/Documentation/driver-api/media/mc-core.rst index 05bba0b61748..57b5bbba944e 100644 --- a/Documentation/driver-api/media/mc-core.rst +++ b/Documentation/driver-api/media/mc-core.rst @@ -36,7 +36,7 @@ pad to a sink pad. Media device ^^^^^^^^^^^^ -A media device is represented by a struct :c:type:`media_device` +A media device is represented by a struct media_device instance, defined in ``include/media/media-device.h``. Allocation of the structure is handled by the media device driver, usually by embedding the :c:type:`media_device` instance in a larger driver-specific @@ -49,7 +49,7 @@ and unregistered by calling :c:func:`media_device_unregister()`. Entities ^^^^^^^^ -Entities are represented by a struct :c:type:`media_entity` +Entities are represented by a struct media_entity instance, defined in ``include/media/media-entity.h``. The structure is usually embedded into a higher-level structure, such as :c:type:`v4l2_subdev` or :c:type:`video_device` @@ -67,10 +67,10 @@ Interfaces ^^^^^^^^^^ Interfaces are represented by a -struct :c:type:`media_interface` instance, defined in +struct media_interface instance, defined in ``include/media/media-entity.h``. Currently, only one type of interface is defined: a device node. Such interfaces are represented by a -struct :c:type:`media_intf_devnode`. +struct media_intf_devnode. Drivers initialize and create device node interfaces by calling :c:func:`media_devnode_create()` @@ -79,7 +79,7 @@ and remove them by calling: Pads ^^^^ -Pads are represented by a struct :c:type:`media_pad` instance, +Pads are represented by a struct media_pad instance, defined in ``include/media/media-entity.h``. Each entity stores its pads in a pads array managed by the entity driver. Drivers usually embed the array in a driver-specific structure. @@ -87,8 +87,8 @@ a driver-specific structure. Pads are identified by their entity and their 0-based index in the pads array. -Both information are stored in the struct :c:type:`media_pad`, -making the struct :c:type:`media_pad` pointer the canonical way +Both information are stored in the struct media_pad, +making the struct media_pad pointer the canonical way to store and pass link references. Pads have flags that describe the pad capabilities and state. @@ -104,7 +104,7 @@ Pads have flags that describe the pad capabilities and state. Links ^^^^^ -Links are represented by a struct :c:type:`media_link` instance, +Links are represented by a struct media_link instance, defined in ``include/media/media-entity.h``. There are two types of links: **1. pad to pad links**: @@ -187,7 +187,7 @@ Use count and power handling Due to the wide differences between drivers regarding power management needs, the media controller does not implement power management. However, -the struct :c:type:`media_entity` includes a ``use_count`` +the struct media_entity includes a ``use_count`` field that media drivers can use to track the number of users of every entity for power management needs. @@ -213,11 +213,11 @@ prevent link states from being modified during streaming by calling The function will mark all entities connected to the given entity through enabled links, either directly or indirectly, as streaming. -The struct :c:type:`media_pipeline` instance pointed to by +The struct media_pipeline instance pointed to by the pipe argument will be stored in every entity in the pipeline. -Drivers should embed the struct :c:type:`media_pipeline` +Drivers should embed the struct media_pipeline in higher-level pipeline structures and can then access the -pipeline through the struct :c:type:`media_entity` +pipeline through the struct media_entity pipe field. Calls to :c:func:`media_pipeline_start()` can be nested. diff --git a/Documentation/driver-api/media/v4l2-controls.rst b/Documentation/driver-api/media/v4l2-controls.rst index 5129019afb49..77f42ea3bac7 100644 --- a/Documentation/driver-api/media/v4l2-controls.rst +++ b/Documentation/driver-api/media/v4l2-controls.rst @@ -27,7 +27,7 @@ V4L2 specification with respect to controls in a central place. And to make life as easy as possible for the driver developer. Note that the control framework relies on the presence of a struct -:c:type:`v4l2_device` for V4L2 drivers and struct :c:type:`v4l2_subdev` for +:c:type:`v4l2_device` for V4L2 drivers and struct v4l2_subdev for sub-device drivers. diff --git a/Documentation/driver-api/media/v4l2-dev.rst b/Documentation/driver-api/media/v4l2-dev.rst index 63c064837c00..666330af31ed 100644 --- a/Documentation/driver-api/media/v4l2-dev.rst +++ b/Documentation/driver-api/media/v4l2-dev.rst @@ -67,7 +67,7 @@ You should also set these fields of :c:type:`video_device`: file operation is called this lock will be taken by the core and released afterwards. See the next section for more details. -- :c:type:`video_device`->queue: a pointer to the struct :c:type:`vb2_queue` +- :c:type:`video_device`->queue: a pointer to the struct vb2_queue associated with this device node. If queue is not ``NULL``, and queue->lock is not ``NULL``, then queue->lock is used for the queuing ioctls (``VIDIOC_REQBUFS``, ``CREATE_BUFS``, @@ -81,7 +81,7 @@ You should also set these fields of :c:type:`video_device`: - :c:type:`video_device`->prio: keeps track of the priorities. Used to implement ``VIDIOC_G_PRIORITY`` and ``VIDIOC_S_PRIORITY``. - If left to ``NULL``, then it will use the struct :c:type:`v4l2_prio_state` + If left to ``NULL``, then it will use the struct v4l2_prio_state in :c:type:`v4l2_device`. If you want to have a separate priority state per (group of) device node(s), then you can point it to your own struct :c:type:`v4l2_prio_state`. @@ -95,7 +95,7 @@ You should also set these fields of :c:type:`video_device`: but it is used by both a raw video PCI device (cx8800) and a MPEG PCI device (cx8802). Since the :c:type:`v4l2_device` cannot be associated with two PCI devices at the same time it is setup without a parent device. But when the - struct :c:type:`video_device` is initialized you **do** know which parent + struct video_device is initialized you **do** know which parent PCI device to use and so you set ``dev_device`` to the correct PCI device. If you use :c:type:`v4l2_ioctl_ops`, then you should set @@ -138,7 +138,7 @@ ioctls and locking ------------------ The V4L core provides optional locking services. The main service is the -lock field in struct :c:type:`video_device`, which is a pointer to a mutex. +lock field in struct video_device, which is a pointer to a mutex. If you set this pointer, then that will be used by unlocked_ioctl to serialize all ioctls. diff --git a/Documentation/driver-api/media/v4l2-device.rst b/Documentation/driver-api/media/v4l2-device.rst index 5e25bf182c18..7bd9c45f551b 100644 --- a/Documentation/driver-api/media/v4l2-device.rst +++ b/Documentation/driver-api/media/v4l2-device.rst @@ -3,7 +3,7 @@ V4L2 device instance -------------------- -Each device instance is represented by a struct :c:type:`v4l2_device`. +Each device instance is represented by a struct v4l2_device. Very simple devices can just allocate this struct, but most of the time you would embed this struct inside a larger struct. @@ -18,9 +18,9 @@ dev->driver_data field is ``NULL``, it will be linked to Drivers that want integration with the media device framework need to set dev->driver_data manually to point to the driver-specific device structure -that embed the struct :c:type:`v4l2_device` instance. This is achieved by a +that embed the struct v4l2_device instance. This is achieved by a ``dev_set_drvdata()`` call before registering the V4L2 device instance. -They must also set the struct :c:type:`v4l2_device` mdev field to point to a +They must also set the struct v4l2_device mdev field to point to a properly initialized and registered :c:type:`media_device` instance. If :c:type:`v4l2_dev <v4l2_device>`\ ->name is empty then it will be set to a diff --git a/Documentation/driver-api/media/v4l2-event.rst b/Documentation/driver-api/media/v4l2-event.rst index a4b7ae2b94d8..5b8254eba7da 100644 --- a/Documentation/driver-api/media/v4l2-event.rst +++ b/Documentation/driver-api/media/v4l2-event.rst @@ -44,18 +44,18 @@ such objects. So to summarize: -- struct :c:type:`v4l2_fh` has two lists: one of the ``subscribed`` events, +- struct v4l2_fh has two lists: one of the ``subscribed`` events, and one of the ``available`` events. -- struct :c:type:`v4l2_subscribed_event` has a ringbuffer of raised +- struct v4l2_subscribed_event has a ringbuffer of raised (pending) events of that particular type. -- If struct :c:type:`v4l2_subscribed_event` is associated with a specific +- If struct v4l2_subscribed_event is associated with a specific object, then that object will have an internal list of - struct :c:type:`v4l2_subscribed_event` so it knows who subscribed an + struct v4l2_subscribed_event so it knows who subscribed an event to that object. -Furthermore, the internal struct :c:type:`v4l2_subscribed_event` has +Furthermore, the internal struct v4l2_subscribed_event has ``merge()`` and ``replace()`` callbacks which drivers can set. These callbacks are called when a new event is raised and there is no more room. diff --git a/Documentation/driver-api/media/v4l2-fh.rst b/Documentation/driver-api/media/v4l2-fh.rst index 4c62b19af744..3eeaa8da0c9e 100644 --- a/Documentation/driver-api/media/v4l2-fh.rst +++ b/Documentation/driver-api/media/v4l2-fh.rst @@ -3,11 +3,11 @@ V4L2 File handlers ------------------ -struct :c:type:`v4l2_fh` provides a way to easily keep file handle specific +struct v4l2_fh provides a way to easily keep file handle specific data that is used by the V4L2 framework. .. attention:: - New drivers must use struct :c:type:`v4l2_fh` + New drivers must use struct v4l2_fh since it is also used to implement priority handling (:ref:`VIDIOC_G_PRIORITY`). @@ -16,11 +16,11 @@ whether a driver uses :c:type:`v4l2_fh` as its ``file->private_data`` pointer by testing the ``V4L2_FL_USES_V4L2_FH`` bit in :c:type:`video_device`->flags. This bit is set whenever :c:func:`v4l2_fh_init` is called. -struct :c:type:`v4l2_fh` is allocated as a part of the driver's own file handle +struct v4l2_fh is allocated as a part of the driver's own file handle structure and ``file->private_data`` is set to it in the driver's ``open()`` function by the driver. -In many cases the struct :c:type:`v4l2_fh` will be embedded in a larger +In many cases the struct v4l2_fh will be embedded in a larger structure. In that case you should call: #) :c:func:`v4l2_fh_init` and :c:func:`v4l2_fh_add` in ``open()`` @@ -102,18 +102,18 @@ Below is a short description of the :c:type:`v4l2_fh` functions used: memory can be freed. -If struct :c:type:`v4l2_fh` is not embedded, then you can use these helper functions: +If struct v4l2_fh is not embedded, then you can use these helper functions: :c:func:`v4l2_fh_open <v4l2_fh_open>` (struct file \*filp) -- This allocates a struct :c:type:`v4l2_fh`, initializes it and adds it to - the struct :c:type:`video_device` associated with the file struct. +- This allocates a struct v4l2_fh, initializes it and adds it to + the struct video_device associated with the file struct. :c:func:`v4l2_fh_release <v4l2_fh_release>` (struct file \*filp) -- This deletes it from the struct :c:type:`video_device` associated with the +- This deletes it from the struct video_device associated with the file struct, uninitialised the :c:type:`v4l2_fh` and frees it. These two functions can be plugged into the v4l2_file_operation's ``open()`` diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst index 6248ea99e979..bb5b1a7cdfd9 100644 --- a/Documentation/driver-api/media/v4l2-subdev.rst +++ b/Documentation/driver-api/media/v4l2-subdev.rst @@ -110,7 +110,7 @@ pads: err = media_entity_pads_init(&sd->entity, npads, pads); The pads array must have been previously initialized. There is no need to -manually set the struct :c:type:`media_entity` function and name fields, but the +manually set the struct media_entity function and name fields, but the revision field must be initialized if needed. A reference to the entity will be automatically acquired/released when the diff --git a/Documentation/driver-api/regulator.rst b/Documentation/driver-api/regulator.rst index 520da0a5251d..b43c78eb24d8 100644 --- a/Documentation/driver-api/regulator.rst +++ b/Documentation/driver-api/regulator.rst @@ -116,7 +116,7 @@ core, providing operations structures to the core. A notifier interface allows error conditions to be reported to the core. Registration should be triggered by explicit setup done by the platform, -supplying a struct :c:type:`regulator_init_data` for the regulator +supplying a struct regulator_init_data for the regulator containing constraint and supply information. Machine interface @@ -144,7 +144,7 @@ a given system, for example supporting higher supply voltages than the consumers are rated for. This is done at driver registration time` by providing a -struct :c:type:`regulation_constraints`. +struct regulation_constraints. The constraints may also specify an initial configuration for the regulator in the constraints, which is particularly useful for use with diff --git a/Documentation/driver-api/usb/URB.rst b/Documentation/driver-api/usb/URB.rst index 1e4abc896a0d..a182c0f5e38a 100644 --- a/Documentation/driver-api/usb/URB.rst +++ b/Documentation/driver-api/usb/URB.rst @@ -47,7 +47,7 @@ called USB Request Block, or URB for short. The URB structure ================= -Some of the fields in struct :c:type:`urb` are:: +Some of the fields in struct urb are:: struct urb { diff --git a/Documentation/driver-api/usb/gadget.rst b/Documentation/driver-api/usb/gadget.rst index 3e8a3809c0b8..09396edd6131 100644 --- a/Documentation/driver-api/usb/gadget.rst +++ b/Documentation/driver-api/usb/gadget.rst @@ -176,9 +176,9 @@ Kernel Mode Gadget API Gadget drivers declare themselves through a struct :c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration -for a struct :c:type:`usb_gadget`. The response to a set_configuration usually -involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by -the gadget, and submitting one or more struct :c:type:`usb_request` buffers to +for a struct usb_gadget. The response to a set_configuration usually +involves enabling one or more of the struct usb_ep objects exposed by +the gadget, and submitting one or more struct usb_request buffers to transfer data. Understand those four data types, and their operations, and you will understand how this API works. @@ -339,8 +339,8 @@ multi-configuration devices (also more than one function, but not necessarily sharing a given configuration). There is however an optional framework which makes it easier to reuse and combine functions. -Devices using this framework provide a struct :c:type:`usb_composite_driver`, -which in turn provides one or more struct :c:type:`usb_configuration` +Devices using this framework provide a struct usb_composite_driver, +which in turn provides one or more struct usb_configuration instances. Each such configuration includes at least one struct :c:type:`usb_function`, which packages a user visible role such as "network link" or "mass storage device". Management functions may also exist, diff --git a/Documentation/driver-api/usb/hotplug.rst b/Documentation/driver-api/usb/hotplug.rst index 79663e653ca1..c1e13107c50e 100644 --- a/Documentation/driver-api/usb/hotplug.rst +++ b/Documentation/driver-api/usb/hotplug.rst @@ -122,7 +122,7 @@ and their quirks, might have a MODULE_DEVICE_TABLE like this:: Most USB device drivers should pass these tables to the USB subsystem as well as to the module management subsystem. Not all, though: some driver frameworks connect using interfaces layered over USB, and so they won't -need such a struct :c:type:`usb_driver`. +need such a struct usb_driver. Drivers that connect directly to the USB subsystem should be declared something like this:: diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 423c5a0daf45..4f858b38a412 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -437,7 +437,7 @@ FS_IOC_SET_ENCRYPTION_POLICY The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an empty directory or verifies that a directory or regular file already has the specified encryption policy. It takes in a pointer to a -:c:type:`struct fscrypt_policy_v1` or a :c:type:`struct +struct fscrypt_policy_v1 or a :c:type:`struct fscrypt_policy_v2`, defined as follows:: #define FSCRYPT_POLICY_V1 0 @@ -508,7 +508,7 @@ This structure must be initialized as follows: replaced with ``master_key_identifier``, which is longer and cannot be arbitrarily chosen. Instead, the key must first be added using `FS_IOC_ADD_ENCRYPTION_KEY`_. Then, the ``key_spec.u.identifier`` - the kernel returned in the :c:type:`struct fscrypt_add_key_arg` must + the kernel returned in the struct fscrypt_add_key_arg must be used as the ``master_key_identifier`` in the :c:type:`struct fscrypt_policy_v2`. @@ -590,7 +590,7 @@ FS_IOC_GET_ENCRYPTION_POLICY_EX The FS_IOC_GET_ENCRYPTION_POLICY_EX ioctl retrieves the encryption policy, if any, for a directory or regular file. No additional permissions are required beyond the ability to open the file. It -takes in a pointer to a :c:type:`struct fscrypt_get_policy_ex_arg`, +takes in a pointer to a struct fscrypt_get_policy_ex_arg, defined as follows:: struct fscrypt_get_policy_ex_arg { @@ -680,7 +680,7 @@ the filesystem, making all files on the filesystem which were encrypted using that key appear "unlocked", i.e. in plaintext form. It can be executed on any file or directory on the target filesystem, but using the filesystem's root directory is recommended. It takes in -a pointer to a :c:type:`struct fscrypt_add_key_arg`, defined as +a pointer to a struct fscrypt_add_key_arg, defined as follows:: struct fscrypt_add_key_arg { @@ -710,7 +710,7 @@ follows:: __u8 raw[]; }; -:c:type:`struct fscrypt_add_key_arg` must be zeroed, then initialized +struct fscrypt_add_key_arg must be zeroed, then initialized as follows: - If the key is being added for use by v1 encryption policies, then @@ -860,7 +860,7 @@ The FS_IOC_REMOVE_ENCRYPTION_KEY ioctl removes a claim to a master encryption key from the filesystem, and possibly removes the key itself. It can be executed on any file or directory on the target filesystem, but using the filesystem's root directory is recommended. -It takes in a pointer to a :c:type:`struct fscrypt_remove_key_arg`, +It takes in a pointer to a struct fscrypt_remove_key_arg, defined as follows:: struct fscrypt_remove_key_arg { @@ -1149,7 +1149,7 @@ Encryption context ------------------ An encryption policy is represented on-disk by a :c:type:`struct -fscrypt_context_v1` or a :c:type:`struct fscrypt_context_v2`. It is +fscrypt_context_v1` or a struct fscrypt_context_v2. It is up to individual filesystems to decide where to store it, but normally it would be stored in a hidden extended attribute. It should *not* be exposed by the xattr-related system calls such as getxattr() and diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index 6c8944f6f0f7..895e9711ed88 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -84,7 +84,7 @@ FS_IOC_ENABLE_VERITY -------------------- The FS_IOC_ENABLE_VERITY ioctl enables fs-verity on a file. It takes -in a pointer to a :c:type:`struct fsverity_enable_arg`, defined as +in a pointer to a struct fsverity_enable_arg, defined as follows:: struct fsverity_enable_arg { diff --git a/Documentation/sound/designs/tracepoints.rst b/Documentation/sound/designs/tracepoints.rst index 78bc5572f829..b0a7e3010187 100644 --- a/Documentation/sound/designs/tracepoints.rst +++ b/Documentation/sound/designs/tracepoints.rst @@ -34,20 +34,20 @@ substream. In this procedure, PCM hardware parameters are decided by interaction between applications and ALSA PCM core. Once decided, runtime of the PCM substream keeps the parameters. -The parameters are described in :c:type:`struct snd_pcm_hw_params`. This +The parameters are described in struct snd_pcm_hw_params. This structure includes several types of parameters. Applications set preferable value to these parameters, then execute ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE or SNDRV_PCM_IOCTL_HW_PARAMS. The former is used just for refining available set of parameters. The latter is used for an actual decision of the parameters. -The :c:type:`struct snd_pcm_hw_params` structure has below members: +The struct snd_pcm_hw_params structure has below members: ``flags`` Configurable. ALSA PCM core and some drivers handle this flag to select convenient parameters or change their behaviour. ``masks`` Configurable. This type of parameter is described in - :c:type:`struct snd_mask` and represent mask values. As of PCM protocol + struct snd_mask and represent mask values. As of PCM protocol v2.0.13, three types are defined. - SNDRV_PCM_HW_PARAM_ACCESS @@ -55,7 +55,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: - SNDRV_PCM_HW_PARAM_SUBFORMAT ``intervals`` Configurable. This type of parameter is described in - :c:type:`struct snd_interval` and represent values with a range. As of + struct snd_interval and represent values with a range. As of PCM protocol v2.0.13, twelve types are defined. - SNDRV_PCM_HW_PARAM_SAMPLE_BITS @@ -78,7 +78,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: are going to be changed. ``cmask`` Read-only. After returning from ioctl(2), buffer in user space for - :c:type:`struct snd_pcm_hw_params` includes result of each operation. + struct snd_pcm_hw_params includes result of each operation. This mask represents which mask/interval parameter is actually changed. ``info`` Read-only. This represents hardware/driver capabilities as bit flags @@ -110,10 +110,10 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: value to this parameter but some drivers intentionally set zero with a care of hardware design or data transmission protocol. -ALSA PCM core handles buffer of :c:type:`struct snd_pcm_hw_params` when +ALSA PCM core handles buffer of struct snd_pcm_hw_params when applications execute ioctl(2) with SNDRV_PCM_HW_REFINE or SNDRV_PCM_HW_PARAMS. Parameters in the buffer are changed according to -:c:type:`struct snd_pcm_hardware` and rules of constraints in the runtime. The +struct snd_pcm_hardware and rules of constraints in the runtime. The structure describes capabilities of handled hardware. The rules describes dependencies on which a parameter is decided according to several parameters. A rule has a callback function, and drivers can register arbitrary functions @@ -121,17 +121,17 @@ to compute the target parameter. ALSA PCM core registers some rules to the runtime as a default. Each driver can join in the interaction as long as it prepared for two stuffs -in a callback of :c:type:`struct snd_pcm_ops.open`. +in a callback of struct snd_pcm_ops.open. 1. In the callback, drivers are expected to change a member of - :c:type:`struct snd_pcm_hardware` type in the runtime, according to + struct snd_pcm_hardware type in the runtime, according to capacities of corresponding hardware. 2. In the same callback, drivers are also expected to register additional rules of constraints into the runtime when several parameters have dependencies due to hardware design. The driver can refers to result of the interaction in a callback of -:c:type:`struct snd_pcm_ops.hw_params`, however it should not change the +struct snd_pcm_ops.hw_params, however it should not change the content. Tracepoints in this category are designed to trace changes of the @@ -163,7 +163,7 @@ fields are different according to type of the parameter. For parameters of mask type, the fields represent hexadecimal dump of content of the parameter. For parameters of interval type, the fields represent values of each member of ``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in -:c:type:`struct snd_interval` in this order. +struct snd_interval in this order. Tracepoints in drivers ====================== diff --git a/Documentation/sphinx/parse-headers.pl b/Documentation/sphinx/parse-headers.pl index 00a69aceff44..1910079f984f 100755 --- a/Documentation/sphinx/parse-headers.pl +++ b/Documentation/sphinx/parse-headers.pl @@ -110,7 +110,7 @@ while (<IN>) { ) { my $s = $1; - $structs{$s} = "struct :c:type:`$s`\\ "; + $structs{$s} = "struct $s\\ "; next; } } diff --git a/Documentation/vm/ksm.rst b/Documentation/vm/ksm.rst index d1b7270ad55c..9e37add068e6 100644 --- a/Documentation/vm/ksm.rst +++ b/Documentation/vm/ksm.rst @@ -26,7 +26,7 @@ tree. If a KSM page is shared between less than ``max_page_sharing`` VMAs, the node of the stable tree that represents such KSM page points to a -list of :c:type:`struct rmap_item` and the ``page->mapping`` of the +list of struct rmap_item and the ``page->mapping`` of the KSM page points to the stable tree node. When the sharing passes this threshold, KSM adds a second dimension to diff --git a/Documentation/vm/memory-model.rst b/Documentation/vm/memory-model.rst index 769449734573..9daadf9faba1 100644 --- a/Documentation/vm/memory-model.rst +++ b/Documentation/vm/memory-model.rst @@ -24,7 +24,7 @@ whether it is possible to manually override that default. although it is still in use by several architectures. All the memory models track the status of physical page frames using -:c:type:`struct page` arranged in one or more arrays. +struct page arranged in one or more arrays. Regardless of the selected memory model, there exists one-to-one mapping between the physical page frame number (PFN) and the @@ -111,7 +111,7 @@ maps for non-volatile memory devices and deferred initialization of the memory map for larger systems. The SPARSEMEM model presents the physical memory as a collection of -sections. A section is represented with :c:type:`struct mem_section` +sections. A section is represented with struct mem_section that contains `section_mem_map` that is, logically, a pointer to an array of struct pages. However, it is stored with some other magic that aids the sections management. The section size and maximal number @@ -172,7 +172,7 @@ management. The virtually mapped memory map allows storing `struct page` objects for persistent memory devices in pre-allocated storage on those -devices. This storage is represented with :c:type:`struct vmem_altmap` +devices. This storage is represented with struct vmem_altmap that is eventually passed to vmemmap_populate() through a long chain of function calls. The vmemmap_populate() implementation may use the `vmem_altmap` along with :c:func:`vmemmap_alloc_block_buf` helper to diff --git a/mm/ksm.c b/mm/ksm.c index 9afccc36dbd2..0960750bb316 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -81,7 +81,7 @@ * different KSM page copy of that content * * Internally, the regular nodes, "dups" and "chains" are represented - * using the same :c:type:`struct stable_node` structure. + * using the same struct stable_node structure. * * In addition to the stable tree, KSM uses a second data structure called the * unstable tree: this tree holds pointers to pages which have been found to diff --git a/mm/memblock.c b/mm/memblock.c index 326c6b3fec1d..b68ee86788af 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -48,12 +48,12 @@ * boot regardless of the possible restrictions and memory hot(un)plug; * the ``physmem`` type is only available on some architectures. * - * Each region is represented by :c:type:`struct memblock_region` that + * Each region is represented by struct memblock_region that * defines the region extents, its attributes and NUMA node id on NUMA * systems. Every memory type is described by the struct memblock_type * which contains an array of memory regions along with * the allocator metadata. The "memory" and "reserved" types are nicely - * wrapped with :c:type:`struct memblock`. This structure is statically + * wrapped with struct memblock. This structure is statically * initialized at build time. The region arrays are initially sized to * %INIT_MEMBLOCK_REGIONS for "memory" and %INIT_MEMBLOCK_RESERVED_REGIONS * for "reserved". The region array for "physmem" is initially sized to -- 2.26.2

2 1

[PATCH] sound: usb: endpoint.c: fix repeated word 'there'
by Randy Dunlap 06 Oct '20

06 Oct '20

Drop the duplicated word "there". Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: alsa-devel(a)alsa-project.org --- sound/usb/endpoint.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-59-rc8.orig/sound/usb/endpoint.c +++ lnx-59-rc8/sound/usb/endpoint.c @@ -318,7 +318,7 @@ static inline void prepare_inbound_urb(s /* * Send output urbs that have been prepared previously. URBs are dequeued - * from ep->ready_playback_urbs and in case there there aren't any available + * from ep->ready_playback_urbs and in case there aren't any available * or there are no packets that have been prepared, this function does * nothing. *

2 1

[PATCH] sound: drivers: portman2x4: fix repeated word 'if'
by Randy Dunlap 06 Oct '20

06 Oct '20

Correct duplicated word "if" to "if it". Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: alsa-devel(a)alsa-project.org --- sound/drivers/portman2x4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-59-rc8.orig/sound/drivers/portman2x4.c +++ lnx-59-rc8/sound/drivers/portman2x4.c @@ -467,7 +467,7 @@ static int portman_probe(struct parport parport_write_control(p, 0); /* Reset Strobe=0. */ /* Check if Tx circuitry is functioning properly. If initialized - * unit TxEmpty is false, send out char and see if if goes true. + * unit TxEmpty is false, send out char and see if it goes true. */ /* 8 */ parport_write_control(p, TXDATA0); /* Tx channel 0, strobe off. */

2 1

[PATCH 00/13] ASoC: Intel: Remove obsolete solutions and
by Cezary Rojewski 06 Oct '20

06 Oct '20

Follow up to catpt series as mentioned in: [PATCH v10 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point https://www.spinics.net/lists/alsa-devel/msg116440.html As catpt is a direct replacement to sound/soc/intel/haswell, it leaves a lot of code redudant. The second legacy solution - baytrail - is deprecated for a long time by sound/soc/intel/atom with SOF flavor available too. This series addresses the redudancy and removes obsolete code. Along with the legacy solutions, all orphaned components are removed too. As a consequence, further cleanups are unlocked: sound/soc/intel/skylake becomes the sole user of processing code found in sound/soc/intel/common. Those are not part of this series. Cezary Rojewski (13): ASoC: Intel: Remove haswell solution ASoC: Intel: Remove max98090 support for baytrail solution ASoC: Intel: Remove rt5640 support for baytrail solution ASoC: Intel: Remove baytrail solution ASoC: Intel: Remove SST ACPI component ASoC: Intel: Remove SST firmware components ASoC: Intel: Skylake: Unassign ram_read and read_write ops ASoC: Intel: Remove unused DSP operations ASoC: Intel: Remove unused DSP interface fields ASoC: Intel: Remove SST-legacy specific constants ASoC: Intel: Make atom components independent of sst-dsp ASoC: Intel: Remove sst_pdata structure ASoC: Intel: Remove sst_dsp_get_thread_context include/sound/soc-acpi-intel-match.h | 1 - include/trace/events/hswadsp.h | 385 --- sound/soc/intel/Kconfig | 26 - sound/soc/intel/Makefile | 1 - sound/soc/intel/atom/sst/sst.c | 1 - sound/soc/intel/atom/sst/sst.h | 7 + sound/soc/intel/atom/sst/sst_acpi.c | 1 - sound/soc/intel/atom/sst/sst_drv_interface.c | 3 - sound/soc/intel/atom/sst/sst_ipc.c | 1 - sound/soc/intel/atom/sst/sst_loader.c | 1 - sound/soc/intel/atom/sst/sst_pvt.c | 1 - sound/soc/intel/atom/sst/sst_stream.c | 1 - sound/soc/intel/baytrail/Makefile | 5 - sound/soc/intel/baytrail/sst-baytrail-dsp.c | 358 --- sound/soc/intel/baytrail/sst-baytrail-ipc.c | 772 ------ sound/soc/intel/baytrail/sst-baytrail-ipc.h | 64 - sound/soc/intel/baytrail/sst-baytrail-pcm.c | 459 ---- sound/soc/intel/boards/Kconfig | 25 - sound/soc/intel/boards/Makefile | 4 - sound/soc/intel/boards/byt-max98090.c | 182 -- sound/soc/intel/boards/byt-rt5640.c | 224 -- sound/soc/intel/boards/bytcht_es8316.c | 1 - sound/soc/intel/boards/bytcr_rt5640.c | 1 - sound/soc/intel/common/Makefile | 4 - .../intel/common/soc-acpi-intel-byt-match.c | 15 - sound/soc/intel/common/sst-acpi.c | 236 -- sound/soc/intel/common/sst-dsp-priv.h | 284 +-- sound/soc/intel/common/sst-dsp.c | 162 -- sound/soc/intel/common/sst-dsp.h | 222 -- sound/soc/intel/common/sst-firmware.c | 1273 ---------- sound/soc/intel/common/sst-ipc.c | 27 - sound/soc/intel/common/sst-ipc.h | 3 - sound/soc/intel/haswell/Makefile | 5 - sound/soc/intel/haswell/sst-haswell-dsp.c | 705 ------ sound/soc/intel/haswell/sst-haswell-ipc.c | 2222 ----------------- sound/soc/intel/haswell/sst-haswell-ipc.h | 527 ---- sound/soc/intel/haswell/sst-haswell-pcm.c | 1369 ---------- sound/soc/intel/skylake/bxt-sst.c | 2 - sound/soc/intel/skylake/cnl-sst.c | 4 +- sound/soc/intel/skylake/skl-sst-dsp.c | 2 +- sound/soc/intel/skylake/skl-sst-ipc.c | 2 +- sound/soc/intel/skylake/skl-sst.c | 2 - 42 files changed, 11 insertions(+), 9579 deletions(-) delete mode 100644 include/trace/events/hswadsp.h delete mode 100644 sound/soc/intel/baytrail/Makefile delete mode 100644 sound/soc/intel/baytrail/sst-baytrail-dsp.c delete mode 100644 sound/soc/intel/baytrail/sst-baytrail-ipc.c delete mode 100644 sound/soc/intel/baytrail/sst-baytrail-ipc.h delete mode 100644 sound/soc/intel/baytrail/sst-baytrail-pcm.c delete mode 100644 sound/soc/intel/boards/byt-max98090.c delete mode 100644 sound/soc/intel/boards/byt-rt5640.c delete mode 100644 sound/soc/intel/common/sst-acpi.c delete mode 100644 sound/soc/intel/common/sst-firmware.c delete mode 100644 sound/soc/intel/haswell/Makefile delete mode 100644 sound/soc/intel/haswell/sst-haswell-dsp.c delete mode 100644 sound/soc/intel/haswell/sst-haswell-ipc.c delete mode 100644 sound/soc/intel/haswell/sst-haswell-ipc.h delete mode 100644 sound/soc/intel/haswell/sst-haswell-pcm.c -- 2.17.1

5 19

[PATCH] ASoC: mediatek: mt8183-da7219: fix wrong ops for I2S3
by Tzung-Bi Shih 06 Oct '20

06 Oct '20

DA7219 uses I2S2 and I2S3 for input and output respectively. Commit 9e30251fb22e ("ASoC: mediatek: mt8183-da7219: support machine driver with rt1015") introduces a bug that: - If using I2S2 solely, MCLK to DA7219 is 256FS. - If using I2S3 solely, MCLK to DA7219 is 128FS. - If using I2S3 first and then I2S2, the MCLK changes from 128FS to 256FS. As a result, no sound output to the headset. Also no sound input from the headset microphone. Both I2S2 and I2S3 should set MCLK to 256FS. Fixes the wrong ops for I2S3. Fixes: 9e30251fb22e ("ASoC: mediatek: mt8183-da7219: support machine driver with rt1015") Signed-off-by: Tzung-Bi Shih <tzungbi(a)google.com> --- sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c b/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c index 4d69ea31bfe4..c2c1eb16fcc0 100644 --- a/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c +++ b/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c @@ -696,7 +696,7 @@ static int mt8183_da7219_max98357_dev_probe(struct platform_device *pdev) if (card == &mt8183_da7219_max98357_card) { dai_link->be_hw_params_fixup = mt8183_i2s_hw_params_fixup; - dai_link->ops = &mt8183_mt6358_i2s_ops; + dai_link->ops = &mt8183_da7219_i2s_ops; dai_link->cpus = i2s3_max98357a_cpus; dai_link->num_cpus = ARRAY_SIZE(i2s3_max98357a_cpus); -- 2.28.0.806.g8561365e88-goog

2 1

[RFC PATCH 0/2] ALSA: hda - acomp probe fix for i915
by Kai Vehmanen 06 Oct '20

06 Oct '20

Hi, this simple bugfix started to feel a bit like getting stuck in quicksand, so I'm looking for some early input via this RFC series. Basicly hdac_i915.c should not use global state to track communication with i915 driver. But how to get handle of "hdac_bus*? I considered a few options: 1) add hdac_bus as a member of drm_audio_component.h -> seems wrong as this is really an audio side implementation) 2) embed copy of drm_audio_component to 'struct hdac_bus', so I could use container_of() on the device handle to get to the bus -> wasted space to keep a copy at hdac_bus level (note: snd-hda-codec-hdmi do this by embedding a copy of ops to "struct hdmi_spec") 3) add another devres entry to store the hdac_bus directly in acomp_init and a new helper function to query it I now implemented option 3 in this RFC series as it seemed cleanest and most local to hdac_component.c, where the problem stems from. It's still somewhat messy, and I'm wondering if I'm overlooking some obvious alternative. We could dig this deeper into i915 specific code, but OTOH, hdac_bus is an argument snd_hdac_acomp_init(), so it's common for all. Kai Vehmanen (2): ALSA: hda - keep track of HDA core bus instance in acomp ALSA: hda/i915 - fix list corruption with concurrent probes include/sound/hda_component.h | 5 +++++ include/sound/hdaudio.h | 2 ++ sound/hda/hdac_component.c | 34 ++++++++++++++++++++++++++++++++++ sound/hda/hdac_i915.c | 16 +++++++++------- 4 files changed, 50 insertions(+), 7 deletions(-) -- 2.28.0

2 5

[PATCH v5 39/52] docs: writing-an-alsa-driver.rst: fix some bad c:func: markups
by Mauro Carvalho Chehab 06 Oct '20

06 Oct '20

Some such markups are invalid, as reported by Sphinx: ./Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3317: WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*' Invalid C declaration: Expected end of definition. [error at 20] snd_rawmidi_transmit* --------------------^ ./Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3917: WARNING: Unparseable C cross-reference: 'copy_from/to_user' Invalid C declaration: Expected end of definition. [error at 9] copy_from/to_user ---------^ The first case seems to be better replaced by a literal. For the second one, let's generate cross-references, by spliting it in two. Reviewed-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 85d6e9c643ef..73bbd59afc33 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -3315,8 +3315,7 @@ data and removes them from the buffer at once: } If you know beforehand how many bytes you can accept, you can use a -buffer size greater than one with the -:c:func:`snd_rawmidi_transmit\*()` functions. +buffer size greater than one with the ``snd_rawmidi_transmit*()`` functions. The ``trigger`` callback must not sleep. If the hardware FIFO is full before the substream buffer has been emptied, you have to continue @@ -3916,7 +3915,7 @@ the maximum size of the proc file access. The read/write callbacks of raw mode are more direct than the text mode. You need to use a low-level I/O functions such as -:c:func:`copy_from/to_user()` to transfer the data. +:c:func:`copy_from_user()` and :c:func:`copy_to_user()` to transfer the data. :: -- 2.26.2

1 0

[PATCH v5 37/52] docs: sound: writing-an-alsa-driver.rst: get rid of :c:type
by Mauro Carvalho Chehab 06 Oct '20

06 Oct '20

the :c:type shouldn't be used with structs with Sphinx 3, as the C domain there uses .. c:struct for structs. As we have the automarkup extension, let's just get rid of all :c:type as a whole, as those will be automagically marked as such. This solves a bunch of warnings with Sphinx 3, like those: .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:490: WARNING: Unparseable C cross-reference: 'calling snd_card_free' Invalid C declaration: Expected end of definition. [error at 8] calling snd_card_free --------^ .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3328: WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*' Invalid C declaration: Expected end of definition. [error at 20] snd_rawmidi_transmit* --------------------^ .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3928: WARNING: Unparseable C cross-reference: 'copy_from/to_user' Invalid C declaration: Expected end of definition. [error at 9] copy_from/to_user ---------^ Reviewed-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- .../kernel-api/writing-an-alsa-driver.rst | 105 ++++++++---------- 1 file changed, 47 insertions(+), 58 deletions(-) diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index aa9d5ab183d2..85d6e9c643ef 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -194,7 +194,7 @@ The minimum flow for PCI soundcards is as follows: - create ``remove`` callback. -- create a :c:type:`struct pci_driver <pci_driver>` structure +- create a struct pci_driver structure containing the three pointers above. - create an ``init`` function just calling the @@ -487,7 +487,7 @@ The destructor, remove callback, simply releases the card instance. Then the ALSA middle layer will release all the attached components automatically. -It would be typically just :c:func:`calling snd_card_free()`: +It would be typically just calling :c:func:`snd_card_free()`: :: @@ -560,16 +560,15 @@ return the card instance. The extra_size argument is used to allocate card->private_data for the chip-specific data. Note that these data are allocated by :c:func:`snd_card_new()`. -The first argument, the pointer of struct :c:type:`struct device -<device>`, specifies the parent device. For PCI devices, typically -``&pci->`` is passed there. +The first argument, the pointer of struct device, specifies the parent +device. For PCI devices, typically ``&pci->`` is passed there. Components ---------- After the card is created, you can attach the components (devices) to the card instance. In an ALSA driver, a component is represented as a -:c:type:`struct snd_device <snd_device>` object. A component +struct snd_device object. A component can be a PCM instance, a control interface, a raw MIDI interface, etc. Each such instance has one component entry. @@ -628,7 +627,7 @@ argument of :c:func:`snd_card_new()`, i.e. err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, sizeof(struct mychip), &card); -:c:type:`struct mychip <mychip>` is the type of the chip record. +struct mychip is the type of the chip record. In return, the allocated record can be accessed as @@ -890,7 +889,7 @@ functions. These resources must be released in the destructor function (see below). Now assume that the PCI device has an I/O port with 8 bytes and an -interrupt. Then :c:type:`struct mychip <mychip>` will have the +interrupt. Then struct mychip will have the following fields: :: @@ -1094,7 +1093,7 @@ PCI Entries ----------- So far, so good. Let's finish the missing PCI stuff. At first, we need a -:c:type:`struct pci_device_id <pci_device_id>` table for +struct pci_device_id table for this chipset. It's a table of PCI vendor/device ID number, and some masks. @@ -1110,19 +1109,17 @@ For example, }; MODULE_DEVICE_TABLE(pci, snd_mychip_ids); -The first and second fields of the :c:type:`struct pci_device_id -<pci_device_id>` structure are the vendor and device IDs. If you -have no reason to filter the matching devices, you can leave the -remaining fields as above. The last field of the :c:type:`struct -pci_device_id <pci_device_id>` struct contains private data -for this entry. You can specify any value here, for example, to define -specific operations for supported device IDs. Such an example is found -in the intel8x0 driver. +The first and second fields of the struct pci_device_id are the vendor +and device IDs. If you have no reason to filter the matching devices, you can +leave the remaining fields as above. The last field of the +struct pci_device_id contains private data for this entry. You can specify +any value here, for example, to define specific operations for supported +device IDs. Such an example is found in the intel8x0 driver. The last entry of this list is the terminator. You must specify this all-zero entry. -Then, prepare the :c:type:`struct pci_driver <pci_driver>` +Then, prepare the struct pci_driver record: :: @@ -1439,8 +1436,8 @@ corresponding argument. If a chip supports multiple playbacks or captures, you can specify more numbers, but they must be handled properly in open/close, etc. callbacks. When you need to know which substream you are referring to, -then it can be obtained from :c:type:`struct snd_pcm_substream -<snd_pcm_substream>` data passed to each callback as follows: +then it can be obtained from struct snd_pcm_substream data passed to each +callback as follows: :: @@ -1639,10 +1636,9 @@ In the sections below, important records are explained. Hardware Description ~~~~~~~~~~~~~~~~~~~~ -The hardware descriptor (:c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>`) contains the definitions of the fundamental -hardware configuration. Above all, you'll need to define this in the -`PCM open callback`_. Note that the runtime instance holds the copy of +The hardware descriptor (struct snd_pcm_hardware) contains the definitions of +the fundamental hardware configuration. Above all, you'll need to define this +in the `PCM open callback`_. Note that the runtime instance holds the copy of the descriptor, not the pointer to the existing descriptor. That is, in the open callback, you can modify the copied descriptor (``runtime->hw``) as you need. For example, if the maximum number of @@ -1800,14 +1796,13 @@ Running Status ~~~~~~~~~~~~~~ The running status can be referred via ``runtime->status``. This is -the pointer to the :c:type:`struct snd_pcm_mmap_status -<snd_pcm_mmap_status>` record. For example, you can get the current +the pointer to the struct snd_pcm_mmap_status record. +For example, you can get the current DMA hardware pointer via ``runtime->status->hw_ptr``. The DMA application pointer can be referred via ``runtime->control``, -which points to the :c:type:`struct snd_pcm_mmap_control -<snd_pcm_mmap_control>` record. However, accessing directly to -this value is not recommended. +which points to the struct snd_pcm_mmap_control record. +However, accessing directly to this value is not recommended. Private Data ~~~~~~~~~~~~ @@ -1843,8 +1838,8 @@ error number such as ``-EINVAL``. To choose an appropriate error number, it is advised to check what value other parts of the kernel return when the same kind of request fails. -The callback function takes at least the argument with :c:type:`struct -snd_pcm_substream <snd_pcm_substream>` pointer. To retrieve the chip +The callback function takes at least the argument with +struct snd_pcm_substream pointer. To retrieve the chip record from the given substream instance, you can use the following macro. @@ -2313,10 +2308,10 @@ non-atomic contexts. For example, the function :c:func:`snd_pcm_period_elapsed()` is called typically from the interrupt handler. But, if you set up the driver to use a threaded interrupt handler, this call can be in non-atomic context, too. In such -a case, you can set ``nonatomic`` filed of :c:type:`struct snd_pcm -<snd_pcm>` object after creating it. When this flag is set, mutex -and rwsem are used internally in the PCM core instead of spin and -rwlocks, so that you can call all PCM functions safely in a non-atomic +a case, you can set ``nonatomic`` filed of struct snd_pcm object +after creating it. When this flag is set, mutex and rwsem are used internally +in the PCM core instead of spin and rwlocks, so that you can call all PCM +functions safely in a non-atomic context. Constraints @@ -2357,8 +2352,7 @@ There are many different constraints. Look at ``sound/pcm.h`` for a complete list. You can even define your own constraint rules. For example, let's suppose my_chip can manage a substream of 1 channel if and only if the format is ``S16_LE``, otherwise it supports any format -specified in the :c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>` structure (or in any other +specified in struct snd_pcm_hardware> (or in any other constraint_list). You can build a rule like this: :: @@ -2467,7 +2461,7 @@ Definition of Controls To create a new control, you need to define the following three callbacks: ``info``, ``get`` and ``put``. Then, define a -:c:type:`struct snd_kcontrol_new <snd_kcontrol_new>` record, such as: +struct snd_kcontrol_new record, such as: :: @@ -2602,8 +2596,8 @@ info callback ~~~~~~~~~~~~~ The ``info`` callback is used to get detailed information on this -control. This must store the values of the given :c:type:`struct -snd_ctl_elem_info <snd_ctl_elem_info>` object. For example, +control. This must store the values of the given +struct snd_ctl_elem_info object. For example, for a boolean control with a single element: :: @@ -2774,13 +2768,11 @@ In the simplest way, you can do like this: if (err < 0) return err; -where ``my_control`` is the :c:type:`struct snd_kcontrol_new -<snd_kcontrol_new>` object defined above, and chip is the object -pointer to be passed to kcontrol->private_data which can be referred -to in callbacks. +where ``my_control`` is the struct snd_kcontrol_new object defined above, +and chip is the object pointer to be passed to kcontrol->private_data which +can be referred to in callbacks. -:c:func:`snd_ctl_new1()` allocates a new :c:type:`struct -snd_kcontrol <snd_kcontrol>` instance, and +:c:func:`snd_ctl_new1()` allocates a new struct snd_kcontrol instance, and :c:func:`snd_ctl_add()` assigns the given control component to the card. @@ -2797,10 +2789,9 @@ can call :c:func:`snd_ctl_notify()`. For example, This function takes the card pointer, the event-mask, and the control id pointer for the notification. The event-mask specifies the types of notification, for example, in the above example, the change of control -values is notified. The id pointer is the pointer of :c:type:`struct -snd_ctl_elem_id <snd_ctl_elem_id>` to be notified. You can -find some examples in ``es1938.c`` or ``es1968.c`` for hardware volume -interrupts. +values is notified. The id pointer is the pointer of struct snd_ctl_elem_id +to be notified. You can find some examples in ``es1938.c`` or ``es1968.c`` +for hardware volume interrupts. Metadata -------- @@ -2915,9 +2906,8 @@ with an ``ac97_bus_ops_t`` record with callback functions. The bus record is shared among all belonging ac97 instances. -And then call :c:func:`snd_ac97_mixer()` with an :c:type:`struct -snd_ac97_template <snd_ac97_template>` record together with -the bus pointer created above. +And then call :c:func:`snd_ac97_mixer()` with an struct snd_ac97_template +record together with the bus pointer created above. :: @@ -3118,11 +3108,10 @@ devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see Usually, the port address corresponds to the command port and port + 1 corresponds to the data port. If not, you may change the ``cport`` -field of :c:type:`struct snd_mpu401 <snd_mpu401>` manually afterward. -However, :c:type:`struct snd_mpu401 <snd_mpu401>` pointer is +field of struct snd_mpu401 manually afterward. +However, struct snd_mpu401 pointer is not returned explicitly by :c:func:`snd_mpu401_uart_new()`. You -need to cast ``rmidi->private_data`` to :c:type:`struct snd_mpu401 -<snd_mpu401>` explicitly, +need to cast ``rmidi->private_data`` to struct snd_mpu401 explicitly, :: @@ -3772,7 +3761,7 @@ For creating the SG-buffer handler, call :c:func:`snd_pcm_set_managed_buffer_all()` with ``SNDRV_DMA_TYPE_DEV_SG`` in the PCM constructor like other PCI pre-allocator. You need to pass ``&pci->dev``, where pci is -the :c:type:`struct pci_dev <pci_dev>` pointer of the chip as +the struct pci_dev pointer of the chip as well. :: -- 2.26.2

1 0

[PATCH v5 28/52] docs: remove sound API duplication
by Mauro Carvalho Chehab 06 Oct '20

06 Oct '20

The sound API is documented on two different parts: under Documentation/driver-api/sound.rst and under Documentation/sound/kernel-api/alsa-driver-api.rst. The alsa-driver-api.rst seems more complete, and APIs are split per type. There's just one missing kernel-doc markup there. Add it and drop the duplicated one. Reviewed-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- Documentation/driver-api/index.rst | 1 - Documentation/driver-api/sound.rst | 54 ------------------- .../sound/kernel-api/alsa-driver-api.rst | 1 + 3 files changed, 1 insertion(+), 55 deletions(-) delete mode 100644 Documentation/driver-api/sound.rst diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 6e7c702e0268..987d6e74ea6a 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -27,7 +27,6 @@ available subsections can be seen below. component message-based infiniband - sound frame-buffer regulator iio/index diff --git a/Documentation/driver-api/sound.rst b/Documentation/driver-api/sound.rst deleted file mode 100644 index afef6eabc073..000000000000 --- a/Documentation/driver-api/sound.rst +++ /dev/null @@ -1,54 +0,0 @@ -Sound Devices -============= - -.. kernel-doc:: include/sound/core.h - :internal: - -.. kernel-doc:: sound/sound_core.c - :export: - -.. kernel-doc:: include/sound/pcm.h - :internal: - -.. kernel-doc:: sound/core/pcm.c - :export: - -.. kernel-doc:: sound/core/device.c - :export: - -.. kernel-doc:: sound/core/info.c - :export: - -.. kernel-doc:: sound/core/rawmidi.c - :export: - -.. kernel-doc:: sound/core/sound.c - :export: - -.. kernel-doc:: sound/core/memory.c - :export: - -.. kernel-doc:: sound/core/pcm_memory.c - :export: - -.. kernel-doc:: sound/core/init.c - :export: - -.. kernel-doc:: sound/core/isadma.c - :export: - -.. kernel-doc:: sound/core/control.c - :export: - -.. kernel-doc:: sound/core/pcm_lib.c - :export: - -.. kernel-doc:: sound/core/hwdep.c - :export: - -.. kernel-doc:: sound/core/pcm_native.c - :export: - -.. kernel-doc:: sound/core/memalloc.c - :export: - diff --git a/Documentation/sound/kernel-api/alsa-driver-api.rst b/Documentation/sound/kernel-api/alsa-driver-api.rst index c8cc651eccf7..d24c64df7069 100644 --- a/Documentation/sound/kernel-api/alsa-driver-api.rst +++ b/Documentation/sound/kernel-api/alsa-driver-api.rst @@ -132,3 +132,4 @@ ISA DMA Helpers Other Helper Macros ------------------- .. kernel-doc:: include/sound/core.h +.. kernel-doc:: sound/sound_core.c -- 2.26.2

1 0

[PATCH] dt-bindings: Another round of adding missing 'additionalProperties'
by Rob Herring 06 Oct '20

06 Oct '20

Another round of wack-a-mole. The json-schema default is additional unknown properties are allowed, but for DT all properties should be defined. Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: Stephen Boyd <sboyd(a)kernel.org> Cc: Shawn Guo <shawnguo(a)kernel.org> Cc: Bjorn Andersson <bjorn.andersson(a)linaro.org> Cc: Baolin Wang <baolin.wang7(a)gmail.com> Cc: Guenter Roeck <linux(a)roeck-us.net> Cc: Jonathan Cameron <jic23(a)kernel.org> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Cc: Lee Jones <lee.jones(a)linaro.org> Cc: Ulf Hansson <ulf.hansson(a)linaro.org> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: Vinod Koul <vkoul(a)kernel.org> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Daniel Lezcano <daniel.lezcano(a)linaro.org> Cc: linux-clk(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linux-spi(a)vger.kernel.org Cc: linux-gpio(a)vger.kernel.org Cc: linux-hwmon(a)vger.kernel.org Cc: linux-iio(a)vger.kernel.org Cc: openipmi-developer(a)lists.sourceforge.net Cc: linux-leds(a)vger.kernel.org Cc: linux-media(a)vger.kernel.org Cc: linux-rockchip(a)lists.infradead.org Cc: linux-stm32(a)st-md-mailman.stormreply.com Cc: linux-mips(a)vger.kernel.org Cc: linux-mmc(a)vger.kernel.org Cc: netdev(a)vger.kernel.org Cc: linux-pci(a)vger.kernel.org Cc: linux-pm(a)vger.kernel.org Cc: linux-remoteproc(a)vger.kernel.org Cc: linux-serial(a)vger.kernel.org Cc: alsa-devel(a)alsa-project.org Cc: linux-usb(a)vger.kernel.org Signed-off-by: Rob Herring <robh(a)kernel.org> --- I'll take this thru the DT tree. .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 2 ++ .../arm/mediatek/mediatek,pericfg.yaml | 2 ++ .../devicetree/bindings/arm/pmu.yaml | 2 ++ .../devicetree/bindings/arm/primecell.yaml | 3 +++ .../bindings/arm/samsung/sysreg.yaml | 2 ++ .../arm/tegra/nvidia,tegra20-pmc.yaml | 2 ++ .../bindings/bus/mti,mips-cdmm.yaml | 2 ++ .../bus/socionext,uniphier-system-bus.yaml | 7 +++++++ .../bindings/clock/arm,syscon-icst.yaml | 2 ++ .../bindings/clock/idt,versaclock5.yaml | 20 ++++++++++--------- .../bindings/clock/imx6q-clock.yaml | 2 ++ .../bindings/clock/imx6sl-clock.yaml | 2 ++ .../bindings/clock/imx6sll-clock.yaml | 2 ++ .../bindings/clock/imx6sx-clock.yaml | 2 ++ .../bindings/clock/imx6ul-clock.yaml | 2 ++ .../bindings/clock/intel,cgu-lgm.yaml | 2 ++ .../bindings/clock/qcom,gcc-sm8250.yaml | 2 ++ .../bindings/clock/sprd,sc9863a-clk.yaml | 2 ++ .../bindings/clock/ti,am654-ehrpwm-tbclk.yaml | 2 ++ .../bindings/display/bridge/ite,it6505.yaml | 5 +++++ .../bindings/display/bridge/lvds-codec.yaml | 3 +++ .../devicetree/bindings/display/msm/gmu.yaml | 2 ++ .../devicetree/bindings/edac/dmc-520.yaml | 2 ++ .../devicetree/bindings/fsi/ibm,fsi2spi.yaml | 2 ++ .../gpio/socionext,uniphier-gpio.yaml | 2 ++ .../bindings/hwmon/adi,axi-fan-control.yaml | 2 ++ .../devicetree/bindings/hwmon/adt7475.yaml | 2 ++ .../bindings/iio/accel/kionix,kxsd9.yaml | 4 ++++ .../bindings/iio/adc/maxim,max1238.yaml | 2 ++ .../bindings/iio/adc/maxim,max1363.yaml | 2 ++ .../bindings/iio/adc/qcom,spmi-vadc.yaml | 4 ++++ .../bindings/iio/adc/samsung,exynos-adc.yaml | 2 ++ .../bindings/iio/adc/ti,ads8688.yaml | 4 ++++ .../bindings/iio/amplifiers/adi,hmc425a.yaml | 2 ++ .../bindings/iio/imu/invensense,icm42600.yaml | 6 ++++++ .../bindings/iio/light/amstaos,tsl2563.yaml | 2 ++ .../bindings/iio/light/dynaimage,al3010.yaml | 2 ++ .../bindings/iio/light/dynaimage,al3320a.yaml | 2 ++ .../bindings/iio/light/sharp,gp2ap002.yaml | 2 ++ .../iio/magnetometer/asahi-kasei,ak8975.yaml | 2 ++ .../iio/proximity/vishay,vcnl3020.yaml | 2 ++ .../interrupt-controller/ingenic,intc.yaml | 2 ++ .../loongson,pch-msi.yaml | 2 ++ .../loongson,pch-pic.yaml | 2 ++ .../devicetree/bindings/ipmi/ipmi-smic.yaml | 2 ++ .../devicetree/bindings/leds/leds-lp55xx.yaml | 8 ++++++++ .../bindings/media/i2c/chrontel,ch7322.yaml | 2 ++ .../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 2 ++ .../bindings/media/nxp,imx8mq-vpu.yaml | 2 ++ .../bindings/media/qcom,msm8916-venus.yaml | 2 ++ .../bindings/media/qcom,msm8996-venus.yaml | 2 ++ .../bindings/media/qcom,sc7180-venus.yaml | 2 ++ .../bindings/media/qcom,sdm845-venus-v2.yaml | 2 ++ .../bindings/media/qcom,sdm845-venus.yaml | 2 ++ .../bindings/memory-controllers/fsl/mmdc.yaml | 2 ++ .../memory-controllers/st,stm32-fmc2-ebi.yaml | 2 ++ .../bindings/mfd/gateworks-gsc.yaml | 2 ++ .../bindings/mfd/xylon,logicvc.yaml | 14 +++++++++++-- .../bindings/mips/ingenic/ingenic,cpu.yaml | 6 ++++-- .../bindings/mips/loongson/rs780e-acpi.yaml | 2 ++ .../bindings/mmc/mmc-pwrseq-emmc.yaml | 2 ++ .../bindings/mmc/mmc-pwrseq-sd8787.yaml | 2 ++ .../bindings/mmc/mmc-pwrseq-simple.yaml | 2 ++ .../devicetree/bindings/net/qcom,ipa.yaml | 2 ++ .../bindings/net/realtek-bluetooth.yaml | 4 +++- .../net/wireless/microchip,wilc1000.yaml | 4 ++++ .../devicetree/bindings/pci/rcar-pci-ep.yaml | 2 ++ .../phy/amlogic,meson-g12a-usb2-phy.yaml | 2 ++ .../bindings/phy/qcom,ipq806x-usb-phy-hs.yaml | 2 ++ .../bindings/phy/qcom,ipq806x-usb-phy-ss.yaml | 2 ++ .../bindings/phy/qcom,qusb2-phy.yaml | 1 + .../bindings/phy/qcom-usb-ipq4019-phy.yaml | 2 ++ .../bindings/pinctrl/cirrus,lochnagar.yaml | 2 ++ .../pinctrl/socionext,uniphier-pinctrl.yaml | 2 ++ .../power/amlogic,meson-sec-pwrc.yaml | 2 ++ .../bindings/power/domain-idle-state.yaml | 2 ++ .../bindings/power/mti,mips-cpc.yaml | 2 ++ .../bindings/power/supply/cw2015_battery.yaml | 2 ++ .../bindings/power/supply/rohm,bd99954.yaml | 8 ++++++++ .../bindings/regulator/silergy,sy8827n.yaml | 2 ++ .../bindings/remoteproc/qcom,pil-info.yaml | 2 ++ .../bindings/serial/samsung_uart.yaml | 2 ++ .../serial/socionext,uniphier-uart.yaml | 2 ++ .../devicetree/bindings/serial/sprd-uart.yaml | 2 ++ .../bindings/soc/qcom/qcom,geni-se.yaml | 1 + .../bindings/sound/amlogic,g12a-toacodec.yaml | 2 ++ .../bindings/sound/amlogic,gx-sound-card.yaml | 2 ++ .../bindings/sound/amlogic,t9015.yaml | 2 ++ .../bindings/sound/cirrus,cs42l51.yaml | 2 ++ .../devicetree/bindings/sound/fsl,easrc.yaml | 2 ++ .../bindings/sound/intel,keembay-i2s.yaml | 2 ++ .../bindings/sound/nvidia,tegra186-dspk.yaml | 2 ++ .../sound/nvidia,tegra210-admaif.yaml | 2 ++ .../bindings/sound/nvidia,tegra210-dmic.yaml | 2 ++ .../bindings/sound/nvidia,tegra210-i2s.yaml | 2 ++ .../bindings/sound/rockchip,rk3328-codec.yaml | 2 ++ .../bindings/sound/tlv320adcx140.yaml | 2 ++ .../bindings/thermal/rcar-thermal.yaml | 5 +++++ .../bindings/thermal/sprd-thermal.yaml | 4 ++++ .../bindings/thermal/thermal-idle.yaml | 2 ++ .../bindings/thermal/thermal-zones.yaml | 2 ++ .../devicetree/bindings/timer/cdns,ttc.yaml | 2 ++ .../bindings/usb/nvidia,tegra-xudc.yaml | 2 ++ .../devicetree/bindings/usb/qcom,dwc3.yaml | 2 ++ .../devicetree/bindings/usb/ti,j721e-usb.yaml | 18 +++++++++++++++++ 105 files changed, 285 insertions(+), 14 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml index 6834f5e8df5f..9fdb319dcf19 100644 --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml @@ -54,6 +54,8 @@ required: - compatible - mboxes +additionalProperties: false + examples: - | firmware { diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml index 1af30174b2d0..8723dfe34bab 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml @@ -47,6 +47,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | pericfg@10003000 { diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml index 97df36d301c9..693ef3f185a8 100644 --- a/Documentation/devicetree/bindings/arm/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/pmu.yaml @@ -93,4 +93,6 @@ properties: required: - compatible +additionalProperties: false + ... diff --git a/Documentation/devicetree/bindings/arm/primecell.yaml b/Documentation/devicetree/bindings/arm/primecell.yaml index 5aae37f1c563..e15fe00aafb2 100644 --- a/Documentation/devicetree/bindings/arm/primecell.yaml +++ b/Documentation/devicetree/bindings/arm/primecell.yaml @@ -33,4 +33,7 @@ properties: contains: const: apb_pclk additionalItems: true + +additionalProperties: true + ... diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml b/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml index 3b7811804cb4..2ac789058eee 100644 --- a/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.yaml @@ -32,6 +32,8 @@ properties: reg: maxItems: 1 +additionalProperties: false + examples: - | syscon@10010000 { diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml index b71a20af5f70..43fd2f8927d0 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml @@ -308,6 +308,8 @@ required: - clocks - '#clock-cells' +additionalProperties: false + dependencies: "nvidia,suspend-mode": ["nvidia,core-pwr-off-time", "nvidia,cpu-pwr-off-time"] "nvidia,core-pwr-off-time": ["nvidia,core-pwr-good-time"] diff --git a/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml b/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml index 9cc2d5f1beef..6a7b26b049f1 100644 --- a/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml +++ b/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml @@ -26,6 +26,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | cdmm@1bde8000 { diff --git a/Documentation/devicetree/bindings/bus/socionext,uniphier-system-bus.yaml b/Documentation/devicetree/bindings/bus/socionext,uniphier-system-bus.yaml index a0c6c5d2b70f..49df13fc2f89 100644 --- a/Documentation/devicetree/bindings/bus/socionext,uniphier-system-bus.yaml +++ b/Documentation/devicetree/bindings/bus/socionext,uniphier-system-bus.yaml @@ -57,6 +57,11 @@ properties: "ranges" property should provide a "reasonable" default that is known to work. The software should initialize the bus controller according to it. +patternProperties: + "^.*@[1-5],[1-9a-f][0-9a-f]+$": + description: Devices attached to chip selects + type: object + required: - compatible - reg @@ -64,6 +69,8 @@ required: - "#size-cells" - ranges +additionalProperties: false + examples: - | // In this example, diff --git a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml index 444aeea27db8..eb241587efd1 100644 --- a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml +++ b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml @@ -89,6 +89,8 @@ required: - compatible - clocks +additionalProperties: false + examples: - | vco1: clock { diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index 28c6461b9a9a..2ac1131fd922 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -50,6 +50,15 @@ properties: '#clock-cells': const: 1 + clock-names: + minItems: 1 + maxItems: 2 + items: + enum: [ xin, clkin ] + clocks: + minItems: 1 + maxItems: 2 + patternProperties: "^OUT[1-4]$": type: object @@ -93,19 +102,12 @@ allOf: maxItems: 1 else: # Devices without builtin crystal - properties: - clock-names: - minItems: 1 - maxItems: 2 - items: - enum: [ xin, clkin ] - clocks: - minItems: 1 - maxItems: 2 required: - clock-names - clocks +additionalProperties: false + examples: - | #include <dt-bindings/clk/versaclock.h> diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.yaml b/Documentation/devicetree/bindings/clock/imx6q-clock.yaml index 92a8e545e212..4f4637eddb8b 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.yaml @@ -57,6 +57,8 @@ required: - interrupts - '#clock-cells' +additionalProperties: false + examples: # Clock Control Module node: - | diff --git a/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml index c97bf95b4150..b83c8f43d664 100644 --- a/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx6sl-clock.yaml @@ -33,6 +33,8 @@ required: - interrupts - '#clock-cells' +additionalProperties: false + examples: # Clock Control Module node: - | diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml index de48924be191..484894a4b23f 100644 --- a/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.yaml @@ -49,6 +49,8 @@ required: - clocks - clock-names +additionalProperties: false + examples: # Clock Control Module node: - | diff --git a/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml b/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml index e50cddee43c3..e6c795657c24 100644 --- a/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx6sx-clock.yaml @@ -53,6 +53,8 @@ required: - clocks - clock-names +additionalProperties: false + examples: # Clock Control Module node: - | diff --git a/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml b/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml index 36ce7667c972..6a51a3f51cd9 100644 --- a/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml @@ -49,6 +49,8 @@ required: - clocks - clock-names +additionalProperties: false + examples: # Clock Control Module node: - | diff --git a/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml b/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml index 6dc1414bfb7f..f3e1a700a2ca 100644 --- a/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml +++ b/Documentation/devicetree/bindings/clock/intel,cgu-lgm.yaml @@ -33,6 +33,8 @@ required: - reg - '#clock-cells' +additionalProperties: false + examples: - | cgu: clock-controller@e0200000 { diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml index a5766ff89082..80bd6caf5bc9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8250.yaml @@ -56,6 +56,8 @@ required: - '#reset-cells' - '#power-domain-cells' +additionalProperties: false + examples: - | #include <dt-bindings/clock/qcom,rpmh.h> diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml index c6d091518650..4069e09cb62d 100644 --- a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml +++ b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml @@ -73,6 +73,8 @@ else: The 'reg' property for the clock node is also required if there is a sub range of registers for the clocks. +additionalProperties: false + examples: - | ap_clk: clock-controller@21500000 { diff --git a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml index 869b18ac88d7..6b419a9878f3 100644 --- a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml +++ b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml @@ -26,6 +26,8 @@ required: - "#clock-cells" - reg +additionalProperties: false + examples: - | ehrpwm_tbclk: syscon@4140 { diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml index 2c500166c65d..efbb3d0117dc 100644 --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml @@ -31,6 +31,9 @@ properties: compatible: const: ite,it6505 + reg: + maxItems: 1 + ovdd-supply: maxItems: 1 description: I/O voltage @@ -63,6 +66,8 @@ required: - reset-gpios - extcon +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 68951d56ebba..e8fa8e901c9f 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -83,6 +83,9 @@ required: - compatible - ports +additionalProperties: false + + examples: - | lvds-encoder { diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml index 53056dd02597..fe55611d2603 100644 --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml @@ -89,6 +89,8 @@ required: - iommus - operating-points-v2 +additionalProperties: false + examples: - | #include <dt-bindings/clock/qcom,gpucc-sdm845.h> diff --git a/Documentation/devicetree/bindings/edac/dmc-520.yaml b/Documentation/devicetree/bindings/edac/dmc-520.yaml index 9272d2bd8634..3b6842e92d1b 100644 --- a/Documentation/devicetree/bindings/edac/dmc-520.yaml +++ b/Documentation/devicetree/bindings/edac/dmc-520.yaml @@ -49,6 +49,8 @@ required: - interrupts - interrupt-names +additionalProperties: false + examples: - | dmc0: dmc@200000 { diff --git a/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml b/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml index b26d4b4be743..e2ca0b000471 100644 --- a/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml +++ b/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml @@ -28,6 +28,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | fsi2spi@1c00 { diff --git a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml index c58ff9a94f45..1a54db04f29d 100644 --- a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml @@ -64,6 +64,8 @@ required: - gpio-ranges - socionext,interrupt-ranges +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml index 7898b9dba5a5..6747b870f297 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml @@ -44,6 +44,8 @@ required: - interrupts - pulses-per-revolution +additionalProperties: false + examples: - | fpga_axi: fpga-axi { diff --git a/Documentation/devicetree/bindings/hwmon/adt7475.yaml b/Documentation/devicetree/bindings/hwmon/adt7475.yaml index dfa821c0aacc..ad0ec9f35bd8 100644 --- a/Documentation/devicetree/bindings/hwmon/adt7475.yaml +++ b/Documentation/devicetree/bindings/hwmon/adt7475.yaml @@ -65,6 +65,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | i2c { diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml index d61ab4fa3d71..390b87242fcb 100644 --- a/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml +++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml @@ -29,10 +29,14 @@ properties: mount-matrix: description: an optional 3x3 mounting rotation matrix. + spi-max-frequency: true + required: - compatible - reg +additionalProperties: false + examples: - | # include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml index cccd3033a55b..50bcd72ac9d6 100644 --- a/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml +++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml @@ -62,6 +62,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | i2c { diff --git a/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml b/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml index 48377549c39a..e04f09f35601 100644 --- a/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml +++ b/Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml @@ -36,6 +36,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | i2c { diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml index 0ca992465a21..7f4f827c57a7 100644 --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml @@ -48,6 +48,8 @@ properties: description: End of conversion interrupt. + io-channel-ranges: true + required: - compatible - reg @@ -232,6 +234,8 @@ allOf: enum: [ 1, 2, 4, 8, 16 ] default: 1 +additionalProperties: false + examples: - | spmi_bus { diff --git a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml index cc3c8ea6a894..16d76482b4ff 100644 --- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml @@ -107,6 +107,8 @@ allOf: items: - const: adc +additionalProperties: false + examples: - | adc: adc@12d10000 { diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml index 97fe6cbb2efa..a0af4b24877f 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml @@ -25,10 +25,14 @@ properties: description: Optional external reference. If not supplied, assume REFSEL input tied low to enable the internal reference. + spi-max-frequency: true + required: - compatible - reg +additionalProperties: false + examples: - | spi { diff --git a/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml b/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml index 5342360e96b1..a557761d8016 100644 --- a/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml +++ b/Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml @@ -33,6 +33,8 @@ required: - compatible - ctrl-gpios +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml index abd8d25e1136..4c1c083d0e92 100644 --- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml +++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml @@ -47,11 +47,17 @@ properties: vddio-supply: description: Regulator that provides power to the bus + spi-max-frequency: true + spi-cpha: true + spi-cpol: true + required: - compatible - reg - interrupts +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/iio/light/amstaos,tsl2563.yaml b/Documentation/devicetree/bindings/iio/light/amstaos,tsl2563.yaml index e201a06d8fdc..60e76bc035a5 100644 --- a/Documentation/devicetree/bindings/iio/light/amstaos,tsl2563.yaml +++ b/Documentation/devicetree/bindings/iio/light/amstaos,tsl2563.yaml @@ -32,6 +32,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | i2c { diff --git a/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml b/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml index f671edda6641..a3a979553e32 100644 --- a/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml +++ b/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml @@ -26,6 +26,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/iio/light/dynaimage,al3320a.yaml b/Documentation/devicetree/bindings/iio/light/dynaimage,al3320a.yaml index 497300239d93..8249be99cff9 100644 --- a/Documentation/devicetree/bindings/iio/light/dynaimage,al3320a.yaml +++ b/Documentation/devicetree/bindings/iio/light/dynaimage,al3320a.yaml @@ -26,6 +26,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/iio/light/sharp,gp2ap002.yaml b/Documentation/devicetree/bindings/iio/light/sharp,gp2ap002.yaml index 12aa16f24772..f8a932be0d10 100644 --- a/Documentation/devicetree/bindings/iio/light/sharp,gp2ap002.yaml +++ b/Documentation/devicetree/bindings/iio/light/sharp,gp2ap002.yaml @@ -61,6 +61,8 @@ required: - sharp,proximity-far-hysteresis - sharp,proximity-close-hysteresis +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml index f0b336ac39c9..a25590a16ba7 100644 --- a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml +++ b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml @@ -55,6 +55,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml b/Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml index 51dba64037f6..fbd3a2e32280 100644 --- a/Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml @@ -47,6 +47,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | i2c { diff --git a/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml index 02a3cf470518..0a046be8d1cd 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml @@ -49,6 +49,8 @@ required: - "#interrupt-cells" - interrupt-controller +additionalProperties: false + examples: - | intc: interrupt-controller@10001000 { diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml index 1b256d9dd92a..1f6fd73d4624 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml @@ -46,6 +46,8 @@ required: - loongson,msi-base-vec - loongson,msi-num-vecs +additionalProperties: true #fixme + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml index a6dcbb2971a9..fdd6a38a31db 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml @@ -41,6 +41,8 @@ required: - interrupt-controller - '#interrupt-cells' +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml index 58fa76ee6176..898e3267893a 100644 --- a/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml +++ b/Documentation/devicetree/bindings/ipmi/ipmi-smic.yaml @@ -49,6 +49,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | smic@fff3a000 { diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml index b1bb3feb0f4d..cd877e817ad1 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml @@ -58,6 +58,12 @@ properties: - 2 # D1~6 with VOUT, D7~9 with VDD - 3 # D1~9 are connected to VOUT + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + patternProperties: "(^led@[0-9a-f]$|led)": type: object @@ -98,6 +104,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | #include <dt-bindings/leds/common.h> diff --git a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml index daa2869377c5..63e5b89d2e0b 100644 --- a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml +++ b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml @@ -49,6 +49,8 @@ required: - reg - interrupts +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml index 107c862a7fc7..3dc06c628e64 100644 --- a/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml +++ b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml @@ -119,6 +119,8 @@ required: - reg - port +additionalProperties: false + examples: - | i2c@e66d8000 { diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml index a2d1cd77c1e2..762be3f96ce9 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml @@ -55,6 +55,8 @@ required: - clocks - clock-names +additionalProperties: false + examples: - | #include <dt-bindings/clock/imx8mq-clock.h> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml index f9606df02d70..59ab16ad12f1 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml @@ -92,6 +92,8 @@ required: - video-decoder - video-encoder +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml index fa0dc6c47f1d..199f45217b4a 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml @@ -119,6 +119,8 @@ required: - video-decoder - video-encoder +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml index 55f2d67ae34e..3cec6dae1139 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml @@ -108,6 +108,8 @@ required: - video-decoder - video-encoder +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml index 157dff8057e9..55f5d439fa61 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml @@ -103,6 +103,8 @@ required: - video-core0 - video-core1 +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml index 084e45e2df62..680f37726fdf 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml @@ -120,6 +120,8 @@ required: - video-core0 - video-core1 +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml index 68484136a510..71547eee9919 100644 --- a/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml @@ -33,6 +33,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | #include <dt-bindings/clock/imx6qdl-clock.h> diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml index 70eaf739036b..cba74205846a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml @@ -194,6 +194,8 @@ required: - clocks - ranges +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml index 9b6eb50606e8..95e47f317ed2 100644 --- a/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml +++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.yaml @@ -144,6 +144,8 @@ required: - "#address-cells" - "#size-cells" +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml b/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml index abc9937506e0..8a1a6625c782 100644 --- a/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml +++ b/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml @@ -26,6 +26,12 @@ properties: reg: maxItems: 1 + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + select: properties: compatible: @@ -36,15 +42,19 @@ select: required: - compatible +patternProperties: + "^gpio@[0-9a-f]+$": + $ref: /schemas/gpio/xylon,logicvc-gpio.yaml# + required: - compatible - reg +additionalProperties: false + examples: - | logicvc: logicvc@43c00000 { compatible = "xylon,logicvc-3.02.a", "syscon", "simple-mfd"; reg = <0x43c00000 0x6000>; - #address-cells = <1>; - #size-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml index 16fa03d65ad5..6df1a9470d8f 100644 --- a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml +++ b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml @@ -32,12 +32,16 @@ properties: clocks: maxItems: 1 + device_type: true + required: - device_type - compatible - reg - clocks +additionalProperties: false + examples: - | #include <dt-bindings/clock/jz4780-cgu.h> @@ -52,7 +56,6 @@ examples: reg = <0>; clocks = <&cgu JZ4780_CLK_CPU>; - clock-names = "cpu"; }; cpu1: cpu@1 { @@ -61,7 +64,6 @@ examples: reg = <1>; clocks = <&cgu JZ4780_CLK_CORE1>; - clock-names = "cpu"; }; }; ... diff --git a/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml b/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml index d317897e1115..7c0f9022202c 100644 --- a/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml +++ b/Documentation/devicetree/bindings/mips/loongson/rs780e-acpi.yaml @@ -23,6 +23,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | isa@0 { diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml index 77f746f57284..1fc7e620f328 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml @@ -36,6 +36,8 @@ required: - compatible - reset-gpios +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml index a68820d31d50..e0169a285aa2 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml @@ -28,6 +28,8 @@ required: - powerdown-gpios - reset-gpios +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml index 449215444723..06bbd8590544 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml @@ -50,6 +50,8 @@ properties: required: - compatible +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 8594f114f016..4d8464b2676d 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -144,6 +144,8 @@ oneOf: - required: - memory-region +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml index c488f24ed38f..4f485df69ac3 100644 --- a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml @@ -37,6 +37,8 @@ properties: required: - compatible +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> @@ -49,6 +51,6 @@ examples: bluetooth { compatible = "realtek,rtl8723bs-bt"; device-wake-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */ - host-wakeup-gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */ + host-wake-gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */ }; }; diff --git a/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml b/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml index 2c320eb2a8c4..6c35682377e6 100644 --- a/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml +++ b/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml @@ -18,6 +18,8 @@ properties: compatible: const: microchip,wilc1000 + reg: true + spi-max-frequency: true interrupts: @@ -34,6 +36,8 @@ required: - compatible - interrupts +additionalProperties: false + examples: - | spi { diff --git a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml index aa483c7f27fd..53d5952b7e57 100644 --- a/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml +++ b/Documentation/devicetree/bindings/pci/rcar-pci-ep.yaml @@ -55,6 +55,8 @@ required: - clock-names - max-functions +additionalProperties: false + examples: - | #include <dt-bindings/clock/r8a774c0-cpg-mssr.h> diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml index 0d2557bb0bcc..399ebde45409 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml @@ -63,6 +63,8 @@ then: required: - power-domains +additionalProperties: false + examples: - | phy@36000 { diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml index 23887ebe08fd..17f132ce5516 100644 --- a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml @@ -42,6 +42,8 @@ required: - clocks - clock-names +additionalProperties: false + examples: - | #include <dt-bindings/clock/qcom,gcc-ipq806x.h> diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml index fa30c24b4405..17fd7f6b83bb 100644 --- a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml @@ -60,6 +60,8 @@ required: - clocks - clock-names +additionalProperties: false + examples: - | #include <dt-bindings/clock/qcom,gcc-ipq806x.h> diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index ccda92859eca..d457fb6a4779 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -158,6 +158,7 @@ required: - vdda-phy-dpdm-supply - resets +additionalProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml b/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml index 1118fe69b611..3e7191b168fb 100644 --- a/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml @@ -36,6 +36,8 @@ required: - reset-names - "#phy-cells" +additionalProperties: false + examples: - | #include <dt-bindings/clock/qcom,gcc-ipq4019.h> diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml index 420d74856032..a07dd197176a 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml @@ -188,3 +188,5 @@ required: - gpio-ranges - pinctrl-0 - pinctrl-names + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml index f8a93d8680f9..502480a19f49 100644 --- a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml @@ -28,6 +28,8 @@ properties: required: - compatible +additionalProperties: false + examples: - | // The UniPhier pinctrl should be a subnode of a "syscon" compatible node. diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml index bc4e037f3f73..5dae04d2936c 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml @@ -27,6 +27,8 @@ required: - compatible - "#power-domain-cells" +additionalProperties: false + examples: - | secure-monitor { diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.yaml b/Documentation/devicetree/bindings/power/domain-idle-state.yaml index dfba1af9abe5..6a12efdf436a 100644 --- a/Documentation/devicetree/bindings/power/domain-idle-state.yaml +++ b/Documentation/devicetree/bindings/power/domain-idle-state.yaml @@ -50,6 +50,8 @@ patternProperties: - exit-latency-us - min-residency-us +additionalProperties: false + examples: - | diff --git a/Documentation/devicetree/bindings/power/mti,mips-cpc.yaml b/Documentation/devicetree/bindings/power/mti,mips-cpc.yaml index ccdeaece169e..be447ccfdcb8 100644 --- a/Documentation/devicetree/bindings/power/mti,mips-cpc.yaml +++ b/Documentation/devicetree/bindings/power/mti,mips-cpc.yaml @@ -26,6 +26,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | cpc@1bde0000 { diff --git a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml index 2036977ecc2f..ee92e6a076ac 100644 --- a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml @@ -52,6 +52,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | i2c { diff --git a/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml b/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml index 7e0f73a898c7..9852d2febf65 100644 --- a/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml +++ b/Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml @@ -112,6 +112,12 @@ properties: # threshold, and the current is below this setting (7 in above chart) # See also Documentation/devicetree/bindings/power/supply/battery.txt + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + monitored-battery: description: phandle of battery characteristics devicetree node @@ -137,6 +143,8 @@ properties: required: - compatible +additionalProperties: false + examples: - | i2c { diff --git a/Documentation/devicetree/bindings/regulator/silergy,sy8827n.yaml b/Documentation/devicetree/bindings/regulator/silergy,sy8827n.yaml index 15983cdc7c28..b222adabc7b4 100644 --- a/Documentation/devicetree/bindings/regulator/silergy,sy8827n.yaml +++ b/Documentation/devicetree/bindings/regulator/silergy,sy8827n.yaml @@ -31,6 +31,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | i2c { diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml index 87c52316ddbd..9282837d64ba 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml @@ -25,6 +25,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | imem@146bf000 { diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 96414ac65d06..21ee627b2ced 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -68,6 +68,8 @@ required: - interrupts - reg +additionalProperties: false + allOf: - if: properties: diff --git a/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml b/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml index 09a30300850c..d490c7c4b967 100644 --- a/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml +++ b/Documentation/devicetree/bindings/serial/socionext,uniphier-uart.yaml @@ -32,6 +32,8 @@ required: - interrupts - clocks +additionalProperties: false + examples: - | aliases { diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.yaml b/Documentation/devicetree/bindings/serial/sprd-uart.yaml index e66b2e92a7fc..09f6283f3cae 100644 --- a/Documentation/devicetree/bindings/serial/sprd-uart.yaml +++ b/Documentation/devicetree/bindings/serial/sprd-uart.yaml @@ -56,6 +56,8 @@ required: - reg - interrupts +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index bd04fdb57414..84671950ca0d 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -173,6 +173,7 @@ patternProperties: - compatible - interrupts +additionalProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml b/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml index b4b3828c40af..3c3891d17238 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml @@ -37,6 +37,8 @@ required: - reg - resets +additionalProperties: false + examples: - | #include <dt-bindings/reset/amlogic,meson-g12a-audio-reset.h> diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml index fb374c659be1..db61f0731a20 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml @@ -84,6 +84,8 @@ required: - model - dai-link-0 +additionalProperties: false + examples: - | sound { diff --git a/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml b/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml index 04014e658c90..c7613ea728d4 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml @@ -42,6 +42,8 @@ required: - clock-names - resets +additionalProperties: false + examples: - | #include <dt-bindings/clock/g12a-clkc.h> diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml index 5bcb643c288f..0d87e2c86a42 100644 --- a/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml +++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l51.yaml @@ -46,6 +46,8 @@ required: - reg - "#sound-dai-cells" +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml index 32d547af9ce7..bdde68a1059c 100644 --- a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml @@ -74,6 +74,8 @@ required: - fsl,asrc-rate - fsl,asrc-format +additionalProperties: false + examples: - | #include <dt-bindings/clock/imx8mn-clock.h> diff --git a/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml b/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml index 2e0bbc1c868a..6cbdd8857ea2 100644 --- a/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml @@ -52,6 +52,8 @@ required: - clock-names - interrupts +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml index 2f2fcffa65cb..ed2fb32fcdd4 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml @@ -64,6 +64,8 @@ required: - assigned-clock-parents - sound-name-prefix +additionalProperties: false + examples: - | #include<dt-bindings/clock/tegra186-clock.h> diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml index 41c77f45d2fd..c028b259e822 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml @@ -81,6 +81,8 @@ required: - dmas - dma-names +additionalProperties: false + examples: - | admaif@702d0000 { diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml index 8689d9f18c11..2a3207b550e7 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml @@ -64,6 +64,8 @@ required: - assigned-clocks - assigned-clock-parents +additionalProperties: false + examples: - | #include<dt-bindings/clock/tegra210-car.h> diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml index 9bbf18153d63..dfc1bf7b7722 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml @@ -82,6 +82,8 @@ required: - assigned-clocks - assigned-clock-parents +additionalProperties: false + examples: - | #include<dt-bindings/clock/tegra210-car.h> diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml index 5b85ad5e4834..75b3b33b5f1f 100644 --- a/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml @@ -53,6 +53,8 @@ required: - rockchip,grf - "#sound-dai-cells" +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index f578f17f3e04..1bff53d37118 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -138,6 +138,8 @@ required: - compatible - reg +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml index 0994693d240f..7e9557ac0e4a 100644 --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml @@ -59,6 +59,9 @@ properties: resets: maxItems: 1 + "#thermal-sensor-cells": + const: 0 + if: properties: compatible: @@ -79,6 +82,8 @@ else: - power-domains - resets +additionalProperties: false + examples: # Example (non interrupt support) - | diff --git a/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml b/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml index af2ff930646a..6d65a3cf2af2 100644 --- a/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/sprd-thermal.yaml @@ -68,6 +68,8 @@ patternProperties: - nvmem-cells - nvmem-cell-names + additionalProperties: false + required: - compatible - reg @@ -79,6 +81,8 @@ required: - "#address-cells" - "#size-cells" +additionalProperties: false + examples: - | ap_thm0: thermal@32200000 { diff --git a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml index a832d427e9d5..6278ccf16f3f 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml @@ -44,6 +44,8 @@ properties: required: - '#cooling-cells' +additionalProperties: false + examples: - | #include <dt-bindings/thermal/thermal.h> diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml index 3ec9cc87ec50..164f71598c59 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml @@ -218,6 +218,8 @@ patternProperties: - trips additionalProperties: false +additionalProperties: false + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml index c532b60b9c63..8615353f69b4 100644 --- a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml +++ b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml @@ -36,6 +36,8 @@ required: - interrupts - clocks +additionalProperties: false + examples: - | ttc0: ttc0@f8001000 { diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml index 196589c93373..e60e590dbe12 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml @@ -155,6 +155,8 @@ allOf: clock-names: maxItems: 4 +additionalProperties: false + examples: - | #include <dt-bindings/clock/tegra210-car.h> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index dac10848dd7f..2cf525d21e05 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -121,6 +121,8 @@ required: - interrupts - interrupt-names +additionalProperties: false + examples: - | #include <dt-bindings/clock/qcom,gcc-sdm845.h> diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index 484fc1091d7c..388245b91a55 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -46,6 +46,22 @@ properties: VBUS pin of the SoC via a 1/3 voltage divider. type: boolean + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + '#address-cells': + const: 2 + + '#size-cells': + const: 2 + +patternProperties: + "^usb@": + type: object + required: - compatible - reg @@ -53,6 +69,8 @@ required: - clocks - clock-names +additionalProperties: false + examples: - | #include <dt-bindings/soc/ti,sci_pm_domain.h> -- 2.25.1

12 12

[PATCH] sound: sparc: dbri: fix repeated word 'the'
by Randy Dunlap 05 Oct '20

05 Oct '20

Drop the duplicated word "the". Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: alsa-devel(a)alsa-project.org --- sound/sparc/dbri.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-59-rc8.orig/sound/sparc/dbri.c +++ lnx-59-rc8/sound/sparc/dbri.c @@ -620,7 +620,7 @@ A circular command buffer is used here. while another can be executed. The scheme works by adding two WAIT commands after each sent batch of commands. When the next batch is prepared it is added after the WAIT commands then the WAITs are replaced with single JUMP -command to the new batch. The the DBRI is forced to reread the last WAIT +command to the new batch. The DBRI is forced to reread the last WAIT command (replaced by the JUMP by then). If the DBRI is still executing previous commands the request to reread the WAIT command is ignored.

2 2

[PATCH 1/4] ASoC: Intel: bdw-rt5650: Mark FE DAIs as nonatomic
by Cezary Rojewski 05 Oct '20

05 Oct '20

PCM operations for DAI links connected with DSP platform component involve communication with DSP firmware by IPCs. As IPC protocol may cause thread to sleep while waiting for a response from DSP, propagate that information to ALSA core by marking all FE DAIs as nonatomic. Signed-off-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- sound/soc/intel/boards/bdw-rt5650.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/intel/boards/bdw-rt5650.c b/sound/soc/intel/boards/bdw-rt5650.c index c44315af6a4c..aa420b201848 100644 --- a/sound/soc/intel/boards/bdw-rt5650.c +++ b/sound/soc/intel/boards/bdw-rt5650.c @@ -232,6 +232,7 @@ static struct snd_soc_dai_link bdw_rt5650_dais[] = { { .name = "System PCM", .stream_name = "System Playback", + .nonatomic = 1, .dynamic = 1, .ops = &bdw_rt5650_fe_ops, .trigger = { -- 2.17.1

3 5

[PATCH] ASoC: mediatek: mt8183-da7219: support jack detection for LINEOUT
by Tzung-Bi Shih 05 Oct '20

05 Oct '20

Supports jack detection for LINEOUT. Signed-off-by: Tzung-Bi Shih <tzungbi(a)google.com> --- sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c b/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c index 15e48cde4921..4d69ea31bfe4 100644 --- a/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c +++ b/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c @@ -549,7 +549,8 @@ mt8183_da7219_max98357_headset_init(struct snd_soc_component *component) "Headset Jack", SND_JACK_HEADSET | SND_JACK_BTN_0 | SND_JACK_BTN_1 | - SND_JACK_BTN_2 | SND_JACK_BTN_3, + SND_JACK_BTN_2 | SND_JACK_BTN_3 | + SND_JACK_LINEOUT, &priv->headset_jack, NULL, 0); if (ret) -- 2.28.0.806.g8561365e88-goog

2 1

[PATCH 0/4] ASoC: Intel: sof_sdw: minor corrections
by Pierre-Louis Bossart 05 Oct '20

05 Oct '20

This small patchset adds a missing component string needed by UCM and corrects a confusion on Realtek part numbers. Pierre-Louis Bossart (4): ASoC: Intel: sof_sdw_rt1308: add extra check on init ASoC: Intel: sof_sdw_rt1316: add missing component string ASoC: rt715-sdw: probe with RT714 Device ID ASoC: Intel: sof_sdw: add version_id to avoid rt714/rt715 confusion sound/soc/codecs/rt715-sdw.c | 1 + sound/soc/intel/boards/sof_sdw.c | 16 ++++++++++++++++ sound/soc/intel/boards/sof_sdw_rt1308.c | 4 ++++ sound/soc/intel/boards/sof_sdw_rt1316.c | 6 ++++++ 4 files changed, 27 insertions(+) -- 2.25.1

2 5

[PATCH] ASoC: mchp-spdifrx: convert to devm_platform_get_and_ioremap_resource
by Codrin Ciubotariu 05 Oct '20

05 Oct '20

Use the helper function that wraps the calls to platform_get_resource() and devm_ioremap_resource() together. Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu(a)microchip.com> --- sound/soc/atmel/mchp-spdifrx.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/atmel/mchp-spdifrx.c b/sound/soc/atmel/mchp-spdifrx.c index 6776d89d56df..726e4951d9a5 100644 --- a/sound/soc/atmel/mchp-spdifrx.c +++ b/sound/soc/atmel/mchp-spdifrx.c @@ -873,8 +873,7 @@ static int mchp_spdifrx_probe(struct platform_device *pdev) return -ENOMEM; /* Map I/O registers. */ - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); - base = devm_ioremap_resource(&pdev->dev, mem); + base = devm_platform_get_and_ioremap_resource(pdev, 0, &mem); if (IS_ERR(base)) return PTR_ERR(base); -- 2.25.1

2 1

[PATCH 1/1] ASoC: cs42l51: add soft dependency declaration
by Olivier Moysan 05 Oct '20

05 Oct '20

When configured as module, CS42L51 codec driver uses two modules snd-soc-cs42l51 and snd-soc-cs42l51-i2c. Add soft dependency on snd-soc-cs42l51-i2c in snd-soc-cs42l51, to allow smart module dependency solving. Signed-off-by: Olivier Moysan <olivier.moysan(a)st.com> --- sound/soc/codecs/cs42l51.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/cs42l51.c b/sound/soc/codecs/cs42l51.c index 097c4e8d9950..1630baad42e2 100644 --- a/sound/soc/codecs/cs42l51.c +++ b/sound/soc/codecs/cs42l51.c @@ -814,4 +814,5 @@ EXPORT_SYMBOL_GPL(cs42l51_of_match); MODULE_AUTHOR("Arnaud Patard <arnaud.patard(a)rtp-net.org>"); MODULE_DESCRIPTION("Cirrus Logic CS42L51 ALSA SoC Codec Driver"); +MODULE_SOFTDEP("pre: snd-soc-cs42l51-i2c"); MODULE_LICENSE("GPL"); -- 2.17.1

2 3

Loopback device respond to changing parameters on the other end.
by alsa＠scripple.org 05 Oct '20

05 Oct '20

Hello, Let me open by saying I am not an experienced ALSA developer so hopefully I'm just missing something really easy here. I'm trying to use some DSP programs that insert themselves into the audio chain via the ALSA loopback device. My understanding is that whichever program opens the loopback device first sets the parameters, so the DSP program has to know what parameters any playback program is going to use before it opens its end of the loopback device. And it has to know when to release the loopback device so that another (or the same) playback program can open the loopback device with possibly different parameters. (The DSP program also needs to the know the audio parameters just to do the right thing of course.) I'm not sure how best to accomplish this. I don't want any form of auto-format conversion such as using a resampling or format conversion plugin. I want the DSP program to access the raw PCM stream however it was configured by the playback program. I was thinking I could use the PCM hook system to accomplish what I want. Capture the SND_PCM_HOOK_TYPE_CLOSE (and possibly even use the hook init) to tell the DSP program to close its end of the loopback device. Capture the SND_PCM_HOOK_TYPE_HW_PARAMS to configure the DSP program with the appropriate parameters and tell it to open the loopback device with those new parameters. The init/close part is easy, but I can't figure out how to access the hw_params about to take effect from inside the hook function. If I'm understanding the code correctly the hook function is called from _snd_pcm_hw_params_internal before the PCM interface is actually setup. And snd_pcm_hooks_hw_params chooses not to pass the snd_pcm_hw_params_t structure to the hook function itself, only the snd_pcm_t handle. But since the snd_pcm_t hasn't actually been configured I don't see how to get the new hw_params from it. The hook system does set the new hw_params on the pcm private_data/generic slave device, but I'm not sure how to access that from just libasound2. (Meaning without the full alsa_lib set of includes that define _snd_pcm and such.) I really hoping one can access snd_pcm_hw_params_t inside the hook function. It seems the information really should be there given the callback is triggered by a change to those parameters. Alternatively, is there a better way to automatically configure the read end of the loopback device to match the parameters of the write end? (One that doesn't required modifying every playback program to announce their intentions to the DSP program.) Thanks, scripple

2 2

[PATCH v8 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
by Srinivasa Rao Mandadapu 05 Oct '20

05 Oct '20

These patches are to support audio over DP port on Qualcomm's SC7180 LPASS Asoc. It includes machine driver, cpu driver, platform driver updates for HDMI path support, device tree documention, lpass variant structure optimization and configuration changes. These patches depends on the DP patch series https://patchwork.kernel.org/project/dri-devel/list/?series=332029 https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 changes since V7: -- Fixed typo errors -- Separated buffer size change patche changes since V6: -- Removed compile time define flag, which used for enabling HDMI code, based on corresponding config param is included. -- Updated reg map alloc API with reg map bulk API. -- Removed unnecessary line splits changes since V5: -- Removed unused struct regmap *map in lpass_platform_alloc_hdmidmactl_fields. -- DMA alloc and free API signature change in lpass-apq8016.c, lpass-ipq806x.c -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro Changes Since v4: -- Updated with single compatible node for both I2S and HDMI. Changes Since v3: -- Removed id in lpass variant structure and used snd_soc_dai_driver id. Changes Since v2: -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in lpass-platform.c increased. Changes Since v1: -- Commit messages are updated -- Addressed Rob Herring review comments V Sujith Kumar Reddy (8): ASoC: Add sc7180-lpass binding header hdmi define ASoC: dt-bindings: Add dt binding for lpass hdmi Asoc:qcom:lpass-cpu:Update dts property read API Asoc: qcom: lpass:Update lpaif_dmactl members order ASoC: qcom: Add support for lpass hdmi driver Asoc: qcom: lpass-platform : Increase buffer size ASoC: qcom: sc7180: Add support for audio over DP .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 +++- include/dt-bindings/sound/sc7180-lpass.h | 1 + sound/soc/qcom/Kconfig | 5 + sound/soc/qcom/Makefile | 2 + sound/soc/qcom/lpass-apq8016.c | 4 +- sound/soc/qcom/lpass-cpu.c | 53 ++- sound/soc/qcom/lpass-hdmi.c | 470 +++++++++++++++++++++ sound/soc/qcom/lpass-hdmi.h | 122 ++++++ sound/soc/qcom/lpass-ipq806x.c | 4 +- sound/soc/qcom/lpass-lpaif-reg.h | 52 ++- sound/soc/qcom/lpass-platform.c | 403 ++++++++++++++---- sound/soc/qcom/lpass-sc7180.c | 116 ++++- sound/soc/qcom/lpass.h | 119 +++++- 13 files changed, 1280 insertions(+), 145 deletions(-) create mode 100644 sound/soc/qcom/lpass-hdmi.c create mode 100644 sound/soc/qcom/lpass-hdmi.h -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

3 10

[PATCH v9 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
by Srinivasa Rao Mandadapu 05 Oct '20

05 Oct '20

These patches are to support audio over DP port on Qualcomm's SC7180 LPASS Asoc. It includes machine driver, cpu driver, platform driver updates for HDMI path support, device tree documention, lpass variant structure optimization and configuration changes. These patches depends on the DP patch series https://patchwork.kernel.org/project/dri-devel/list/?series=332029 https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 changes since V8: -- Removed extra structure wrapper for reg map field memebrs -- Updated lpass_hdmi_regmap_volatile API with appropriate registers as true and others as false. changes since V7: -- Fixed typo errors -- Created Separate patch for buffer size change changes since V6: -- Removed compile time define flag, which used for enabling HDMI code, based on corresponding config param is included. -- Updated reg map alloc API with reg map bulk API. -- Removed unnecessary line splits changes since V5: -- Removed unused struct regmap *map in lpass_platform_alloc_hdmidmactl_fields. -- DMA alloc and free API signature change in lpass-apq8016.c, lpass-ipq806x.c -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro Changes Since v4: -- Updated with single compatible node for both I2S and HDMI. Changes Since v3: -- Removed id in lpass variant structure and used snd_soc_dai_driver id. Changes Since v2: -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in lpass-platform.c increased. Changes Since v1: -- Commit messages are updated -- Addressed Rob Herring review comments V Sujith Kumar Reddy (8): ASoC: Add sc7180-lpass binding header hdmi define ASoC: dt-bindings: Add dt binding for lpass hdmi Asoc:qcom:lpass-cpu:Update dts property read API Asoc: qcom: lpass:Update lpaif_dmactl members order ASoC: qcom: Add support for lpass hdmi driver Asoc: qcom: lpass-platform : Increase buffer size ASoC: qcom: sc7180: Add support for audio over DP .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 +++- include/dt-bindings/sound/sc7180-lpass.h | 1 + sound/soc/qcom/Kconfig | 5 + sound/soc/qcom/Makefile | 2 + sound/soc/qcom/lpass-apq8016.c | 4 +- sound/soc/qcom/lpass-cpu.c | 53 ++- sound/soc/qcom/lpass-hdmi.c | 469 +++++++++++++++++++++ sound/soc/qcom/lpass-hdmi.h | 122 ++++++ sound/soc/qcom/lpass-ipq806x.c | 4 +- sound/soc/qcom/lpass-lpaif-reg.h | 52 ++- sound/soc/qcom/lpass-platform.c | 403 ++++++++++++++---- sound/soc/qcom/lpass-sc7180.c | 116 ++++- sound/soc/qcom/lpass.h | 119 +++++- 13 files changed, 1279 insertions(+), 145 deletions(-) create mode 100644 sound/soc/qcom/lpass-hdmi.c create mode 100644 sound/soc/qcom/lpass-hdmi.h -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

1 7

Re: [PATCH 0/6] Ancillary bus implementation and SOF multi-client support
by Leon Romanovsky 05 Oct '20

05 Oct '20

Hi Dave, I don't know why did you send this series separately to every mailing list, but it is not correct thing to do. RDMA ML and discussion: https://lore.kernel.org/linux-rdma/20201001050534.890666-1-david.m.ertman@i… Netdev ML (completely separated): https://lore.kernel.org/netdev/20201001050851.890722-1-david.m.ertman@intel… Alsa ML (separated too): https://lore.kernel.org/alsa-devel/20200930225051.889607-1-david.m.ertman@i… Thanks On Wed, Sep 30, 2020 at 10:05:28PM -0700, Dave Ertman wrote: > Brief history of Ancillary Bus > ============================== > The ancillary bus code was originally submitted upstream as virtual > bus, and was submitted through the netdev tree.  This process generated > up to v4.  This discussion can be found here: > https://lore.kernel.org/netdev/0200520070227.3392100-2-jeffrey.t.kirsher@in… > > At this point, GregKH requested that we take the review and revision > process to an internal mailing list and garner the buy-in of a respected > kernel contributor. > > The ancillary bus (then known as virtual bus) was originally submitted > along with implementation code for the ice driver and irdma drive, > causing the complication of also having dependencies in the rdma tree. > This new submission is utilizing an ancillary bus consumer in only the > sound driver tree to create the initial implementation and a single > user. > > Since implementation work has started on this patch set, there have been > multiple inquiries about the time frame of its completion. It appears > that there will be numerous consumers of this functionality. > > The process of internal review and implementation using the sound > drivers generated 19 internal versions.  The changes, including the name > change from virtual bus to ancillary bus, from these versions can be > summarized as the following: > > - Fixed compilation and checkpatch errors > - Improved documentation to address the motivation for virtual bus. > - Renamed virtual bus to ancillary bus > - increased maximum device name size > - Correct order in Kconfig and Makefile > - removed the mid-layer adev->release layer for device unregister > - pushed adev->id management to parent driver > - all error paths out of ancillary_device_register return error code > - all error paths out of ancillary_device_register use put_device > - added adev->name element > - modname in register cannot be NULL > - added KBUILD_MODNAME as prefix for match_name > - push adev->id responsibility to registering driver > - uevent now parses adev->dev name > - match_id function now parses adev->dev name > - changed drivers probe function to also take an ancillary_device_id param > - split ancillary_device_register into device_initialize and device_add > - adjusted what is done in device_initialize and device_add > - change adev to ancildev and adrv to ancildrv > - change adev to ancildev in documentation > > This submission is the first time that this patch set will be sent to > the alsa-devel mailing list, so it is currently being submitted as > version 1. > > ========================== > > Introduces the ancillary bus implementation along with the example usage > in the Sound Open Firmware(SOF) audio driver. > > In some subsystems, the functionality of the core device > (PCI/ACPI/other) may be too complex for a single device to be managed as > a monolithic block or a part of the functionality might need to be > exposed to a different subsystem. Splitting the functionality into > smaller orthogonal devices makes it easier to manage data, power > management and domain-specific communication with the hardware. Also, > common ancillary_device functionality across primary devices can be > handled by a common ancillary_device. A key requirement for such a split > is that there is no dependency on a physical bus, device, register > accesses or regmap support. These individual devices split from the core > cannot live on the platform bus as they are not physical devices that > are controlled by DT/ACPI. The same argument applies for not using MFD > in this scenario as it relies on individual function devices being > physical devices that are DT enumerated. > > An example for this kind of requirement is the audio subsystem where a > single IP handles multiple entities such as HDMI, Soundwire, local > devices such as mics/speakers etc. The split for the core's > functionality can be arbitrary or be defined by the DSP firmware > topology and include hooks for test/debug. This allows for the audio > core device to be minimal and tightly coupled with handling the > hardware-specific logic and communication. > > The ancillary bus is intended to be minimal, generic and avoid > domain-specific assumptions. Each ancillary bus device represents a part > of its parent functionality. The generic behavior can be extended and > specialized as needed by encapsulating an ancillary bus device within > other domain-specific structures and the use of .ops callbacks. > > The SOF driver adopts the ancillary bus for implementing the > multi-client support. A client in the context of the SOF driver > represents a part of the core device's functionality. It is not a > physical device but rather an ancillary device that needs to communicate > with the DSP via IPCs. With multi-client support,the sound card can be > separated into multiple orthogonal ancillary devices for local devices > (mic/speakers etc), HDMI, sensing, probes, debug etc. In this series, > we demonstrate the usage of the ancillary bus with the help of the IPC > test client which is used for testing the serialization of IPCs when > multiple clients talk to the DSP at the same time. > > Dave Ertman (1): > Add ancillary bus support > > Fred Oh (1): > ASoC: SOF: debug: Remove IPC flood test support in SOF core > > Ranjani Sridharan (4): > ASoC: SOF: Introduce descriptors for SOF client > ASoC: SOF: Create client driver for IPC test > ASoC: SOF: ops: Add ops for client registration > ASoC: SOF: Intel: Define ops for client registration > > Documentation/driver-api/ancillary_bus.rst | 230 +++++++++++++++ > Documentation/driver-api/index.rst | 1 + > drivers/bus/Kconfig | 3 + > drivers/bus/Makefile | 3 + > drivers/bus/ancillary.c | 191 +++++++++++++ > include/linux/ancillary_bus.h | 58 ++++ > include/linux/mod_devicetable.h | 8 + > scripts/mod/devicetable-offsets.c | 3 + > scripts/mod/file2alias.c | 8 + > sound/soc/sof/Kconfig | 29 +- > sound/soc/sof/Makefile | 7 + > sound/soc/sof/core.c | 12 + > sound/soc/sof/debug.c | 230 --------------- > sound/soc/sof/intel/Kconfig | 9 + > sound/soc/sof/intel/Makefile | 3 + > sound/soc/sof/intel/apl.c | 18 ++ > sound/soc/sof/intel/bdw.c | 18 ++ > sound/soc/sof/intel/byt.c | 22 ++ > sound/soc/sof/intel/cnl.c | 18 ++ > sound/soc/sof/intel/intel-client.c | 49 ++++ > sound/soc/sof/intel/intel-client.h | 26 ++ > sound/soc/sof/ops.h | 14 + > sound/soc/sof/sof-client.c | 117 ++++++++ > sound/soc/sof/sof-client.h | 65 +++++ > sound/soc/sof/sof-ipc-test-client.c | 314 +++++++++++++++++++++ > sound/soc/sof/sof-priv.h | 16 +- > 26 files changed, 1233 insertions(+), 239 deletions(-) > create mode 100644 Documentation/driver-api/ancillary_bus.rst > create mode 100644 drivers/bus/ancillary.c > create mode 100644 include/linux/ancillary_bus.h > create mode 100644 sound/soc/sof/intel/intel-client.c > create mode 100644 sound/soc/sof/intel/intel-client.h > create mode 100644 sound/soc/sof/sof-client.c > create mode 100644 sound/soc/sof/sof-client.h > create mode 100644 sound/soc/sof/sof-ipc-test-client.c > > -- > 2.26.2 >

3 4

treewide: fix typos in manual pages
by GitHub pull_request - opened 03 Oct '20

03 Oct '20

alsa-project/alsa-utils pull request #61 was opened from ferivoz: Signed-off-by: Samanta Navarro <ferivoz(a)riseup.net> Request URL : https://github.com/alsa-project/alsa-utils/pull/61 Patch URL : https://github.com/alsa-project/alsa-utils/pull/61.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH v5 00/20] Add Allwinner H3/H5/H6/A64 HDMI audio
by Clément Péron 03 Oct '20

03 Oct '20

Hi, This is exactly the same as v4 but with more details in some commit log and also device-tree soundcard and DAI node have been merged. Regards, Clement Change since v4; - add more comment on get_wss() and set_channel_cfg() patch - merge soundcard and DAI HDMI patches Change since v3: - add Samuel Holland patch to reconfigure FIFO_TX_REG when suspend is enabled - readd inversion to H6 LRCK sun50i_h6_i2s_set_soc_fmt() - Fix get_wss() for sun4i - Add a commit to fix checkpatch warning Change since v2: - rebase on next-20200918 - drop revert LRCK polarity patch - readd simple-audio-card,frame-inversion in dts - Add patch for changing set_chan_cfg params Change since v1: - rebase on next-20200828 - add revert LRCK polarity - remove all simple-audio-card,frame-inversion in dts - add Ondrej patches for Orange Pi board - Add arm64 defconfig patch Clément Péron (6): ASoC: sun4i-i2s: Change set_chan_cfg() params ASoC: sun4i-i2s: Change get_sr() and get_wss() to be more explicit ASoC: sun4i-i2s: Fix sun8i volatile regs arm64: dts: allwinner: h6: Enable HDMI sound for Beelink GS1 arm64: defconfig: Enable Allwinner i2s driver ASoC: sun4i-i2s: fix coding-style for callback definition Jernej Skrabec (3): ASoC: sun4i-i2s: Add support for H6 I2S dt-bindings: ASoC: sun4i-i2s: Add H6 compatible arm64: dts: allwinner: h6: Add DAI node and soundcard for HDMI Marcus Cooper (7): ASoC: sun4i-i2s: Set sign extend sample ASoc: sun4i-i2s: Add 20 and 24 bit support arm: dts: sunxi: h3/h5: Add DAI node and soundcard for HDMI arm64: dts: allwinner: a64: Add DAI node and soundcard for HDMI arm: sun8i: h3: Add HDMI audio to Orange Pi 2 arm: sun8i: h3: Add HDMI audio to Beelink X2 arm64: dts: allwinner: a64: Add HDMI audio to Pine64 Ondrej Jirman (3): arm64: dts: allwinner: Enable HDMI audio on Orange Pi PC 2 ARM: dts: sun8i-h3: Enable HDMI audio on Orange Pi PC/One arm64: dts: sun50i-h6-orangepi-3: Enable HDMI audio Samuel Holland (1): ASoC: sun4i-i2s: Fix setting of FIFO modes .../sound/allwinner,sun4i-a10-i2s.yaml | 2 + arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 8 + arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 + arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 + arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 + arch/arm/boot/dts/sunxi-h3-h5.dtsi | 33 ++ .../boot/dts/allwinner/sun50i-a64-pine64.dts | 8 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 34 ++ .../dts/allwinner/sun50i-h5-orangepi-pc2.dts | 8 + .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 8 + .../dts/allwinner/sun50i-h6-orangepi-3.dts | 8 + arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 33 ++ arch/arm64/configs/defconfig | 1 + sound/soc/sunxi/sun4i-i2s.c | 374 +++++++++++++++--- 14 files changed, 487 insertions(+), 54 deletions(-) -- 2.25.1

3 39

[PATCH] ASoC: hdac_hdmi: remove cancel_work_sync in runtime suspend
by Brent Lu 02 Oct '20

02 Oct '20

A deadlock is identified when there are three contexts running at the same time: - a HDMI jack work which is calling snd_soc_dapm_sync(). - user space is calling snd_pcm_release() to close pcm device. - pm is calling runtime suspend function of HDMI codec driver. By removing the clear_dapm_works() invocation in the hdac_hdmi_runtime_suspend() function, the snd_pcm_release() could always returns from dapm_power_widgets() function call without blocking the hdac_hdmi_jack_dapm_work() work thread or being blocked by the hdac_hdmi_runtime_suspend() function. The purpose of the jack work is to enable/disable the dapm jack pin so it's not necessary to cancel the work in runtime suspend function which is usually called when pcm device is closed. Signed-off-by: Brent Lu <brent.lu(a)intel.com> --- sound/soc/codecs/hdac_hdmi.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index f26b77f..9052edd 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -2097,8 +2097,6 @@ static int hdac_hdmi_runtime_suspend(struct device *dev) if (!bus) return 0; - clear_dapm_works(hdev); - /* * Power down afg. * codec_read is preferred over codec_write to set the power state. -- 2.7.4

3 2

[PATCH -next] ASoC: qcom: fix SDM845 & QDSP6 dependencies more
by Randy Dunlap 02 Oct '20

02 Oct '20

Fix a build error and Kconfig warning in sound/soc/qcom/. ld: sound/soc/qcom/qdsp6/q6afe-clocks.o: in function `q6afe_clock_dev_probe': q6afe-clocks.c:(.text+0x182): undefined reference to `devm_clk_hw_register' ld: q6afe-clocks.c:(.text+0x19d): undefined reference to `of_clk_add_hw_provider' After adding "depends on COMMON_CLK" for SND_SOC_QDSP6, the Kconfig warning appears because "select" does not honor any "depends on" clauses, so fix the dependency for SND_SOC_SDM845 also. WARNING: unmet direct dependencies detected for SND_SOC_QDSP6 Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_QCOM [=y] && QCOM_APR [=y] && COMMON_CLK [=n] Selected by [y]: - SND_SOC_SDM845 [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_QCOM [=y] && QCOM_APR [=y] && I2C [=y] && SOUNDWIRE [=y] Fixes: 520a1c396d19 ("ASoC: q6afe-clocks: add q6afe clock controller") Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Cc: Mark Brown <broonie(a)kernel.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: alsa-devel(a)alsa-project.org --- sound/soc/qcom/Kconfig | 2 ++ 1 file changed, 2 insertions(+) --- linux-next-20201001.orig/sound/soc/qcom/Kconfig +++ linux-next-20201001/sound/soc/qcom/Kconfig @@ -82,6 +82,7 @@ config SND_SOC_QDSP6_ASM_DAI config SND_SOC_QDSP6 tristate "SoC ALSA audio driver for QDSP6" depends on QCOM_APR + depends on COMMON_CLK select SND_SOC_QDSP6_COMMON select SND_SOC_QDSP6_CORE select SND_SOC_QDSP6_AFE @@ -110,6 +111,7 @@ config SND_SOC_MSM8996 config SND_SOC_SDM845 tristate "SoC Machine driver for SDM845 boards" depends on QCOM_APR && I2C && SOUNDWIRE + depends on COMMON_CLK select SND_SOC_QDSP6 select SND_SOC_QCOM_COMMON select SND_SOC_RT5663

3 2

[PATCH] ASoC: fsl_spdif: Remove unused np
by Mark Brown 02 Oct '20

02 Oct '20

Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/fsl/fsl_spdif.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c index 9c5607780590..b0f643fefe1e 100644 --- a/sound/soc/fsl/fsl_spdif.c +++ b/sound/soc/fsl/fsl_spdif.c @@ -1252,7 +1252,6 @@ static int fsl_spdif_probe_txclk(struct fsl_spdif_priv *spdif_priv, static int fsl_spdif_probe(struct platform_device *pdev) { - struct device_node *np = pdev->dev.of_node; struct fsl_spdif_priv *spdif_priv; struct spdif_mixer_control *ctrl; struct resource *res; -- 2.20.1

1 1

[PATCH 0/2] Add driver for Microchip S/PDIF RX
by Codrin Ciubotariu 02 Oct '20

02 Oct '20

The Sony/Philips Digital Interface Receiver (SPDIFRX) is a serial port compliant with the IEC-60958 standard. Among its caracteristics, we mention the following: - SPDIF/AES-EBU Compatible Serial Port - 32 Samples FIFO - Data Width Configurable to 24 bits, 20 bits or 16 bits - Packed and Unpacked Data Support for System Memory Optimization - Line State Events Report and Source of Interrupt - Line Error Rate Report - Full Memory Map of 192 bits for Channel 1 and Channel 2 Status and User Data - First 32-bit Status A, Status B Change Report and Source of Interrupt - Line Digital Filter - Register Write Protection - Abnormal Software Access and Internal Sequencer Integrity Check Reports This interface is available in Microchip's SAMA7G5 SoC. Codrin Ciubotariu (2): dt-bindings: sound: add DT bindings for Microchip S/PDIF RX Controller ASoC: mchp-spdifrx: add driver for SPDIF RX .../bindings/sound/mchp,spdifrx.yaml | 73 ++ sound/soc/atmel/Kconfig | 13 + sound/soc/atmel/Makefile | 2 + sound/soc/atmel/mchp-spdifrx.c | 954 ++++++++++++++++++ 4 files changed, 1042 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml create mode 100644 sound/soc/atmel/mchp-spdifrx.c -- 2.25.1

2 3

[PATCH v10 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point
by Cezary Rojewski 02 Oct '20

02 Oct '20

Implement support for Lynxpoint and Wildcat Point AudioDSP. Catpt solution deprecates existing sound/soc/intel/haswell which is removed in the following series. Due to high range of errors and desynchronization from recommendations set by Windows solution, re-write came as a lower-cost solution compared to refactoring /haswell/ with several series of patches. Series is dependent on linux-spi change: spi: pxa2xx: Add SSC2 and SSPSP2 SSP registers https://www.spinics.net/lists/linux-spi/msg23885.html which has been already merged and is now part of linux-spi tree. Bulk of series content is device driver core code - everything up to patch 7/14 - with fs entries and trace macros introduced right after. While each core patch is shaped in such a way that no unavailable members are ever called, until patch 14/14 is applied, no code compilation can occur as no Makefile is present. Once said patch is added, Makefile and Kconfig are implemented and driver module compiles as expected. Special thanks go to Marcin Barlik and Piotr Papierkowski for sharing their LPT/WPT AudioDSP architecture expertise as well as helping backtrack its historical background. My thanks go to Amadeusz Slawinski for reviews and improvements proposed on and off the internal list. Most of internal diff below is his contribution. Krzysztof Hejmowski helped me setup my own Xtensa environment and recompile LPT/WPT FW binary sources what sped up the development greatly. This would not have been possible without help from these champions, especially considering how quickly the catpt was written: 2 weeks features, 3 weeks optimizations. Thank you. Userspace-exposed members are compatible with what is exposed by deprecated solution as well as FW binary being re-used thus no harm is done. The only visible differences are: the newly added 'Loopback Mute' kcontrol and volume support extending to quad from stereo. On top of fixing erros and design flows, catpt also adds module reload, dynamic SRAM memory allocation during PCM runtime and exposes missing userspace API: 'Loopback Mute' kcontrol, quad volume controls and sysfs fw-version entries. Event tracing is provided to ease solution debugging. Following are not included in this update and are scheduled as later addition: - fw logging - module (library) support Note: LPT power up/down sequences might get aligned with WPT once enough testing is done as capabilities are shared for both DSPs. Note #2: Both LPT and WPT power up/down sequences may get optimized in future updates as thanks to help from the Windows team, most of nuances behind why/what/when in regard to hw registers have been backtracked and reviewed again. Link to developer's deep dive message: https://www.spinics.net/lists/alsa-devel/msg113563.html Changes in v10: - reverted DUAL_MONO case relocation from v9 - indented all constants of enum catpt_module_id to the same column - new newline appended for return path of catpt_dsp_do_send_msg() Changes in v9: https://www.spinics.net/lists/alsa-devel/msg116305.html - fixed newlines in sysfs as requested by Andy, left tags as no other changes done - removed volume_map and replaced by simple formulas for volume kcontrol calculations - removed redundant parentheses in catpt_get_channel_map() and relocated DUAL_MONO case - runtime suspend no longer called during module unload - removed redundant size checks for catpt_dsp_send_tx() and catpt_dsp_copy_rx() Changes in v8: https://www.spinics.net/lists/alsa-devel/msg116168.html - updated catpt_arrange_page_table() with GENMASK and U32_MAX usage - made use of PFN_DOWN() replacing explicit right shitfs by PAGE_SIZE - made fw hash dumping in catpt_coredump() more readable and removed hardcodes - catpt_coredump() dumps fw hash now only if said segment has been found within fw_info - shortened _MSECS suffixes to _MS - IPC structs no longer contain enum members - simplified definition of catpt_set_dspvol() Changes in v7: https://www.spinics.net/lists/alsa-devel/msg116019.html - fixed licence header for fs.c - renamed fs.c to sysfs.c to better match its purpose - added documentation within Documentation/ABI/testing for entries exposed by catpt - bin_attribute fw_build replaced by attribute fw_info: fw_info contains full FW information and after successful handshake, it's always available (stored in driver data) so no need to invoke GET_FW_VERSION IPC again, just dump the stored information - rather than manually creating and removing sysfs files, now makes use of dev_groups member of struct device_driver - patch: 10/14 'ASoC: Intel: Select catpt and deprecate haswell' has been moved to the back of the list: enable catpt after machine boards have been prepared for it first - improved readability of several goto labels Changes in v6: https://www.spinics.net/lists/alsa-devel/msg115765.html - reordered and reorganized code for patches 1/13 - 8/13 of v5, so each patches makes use of no member or function which is unavailable to it. Series size increased from 13 to 14 patches: addition of base members e.g.: registers has been split from addition of device.c file which describes acpi device behavior Changes in v5: https://www.spinics.net/lists/alsa-devel/msg115621.html Basically everything below is result of Andy's review. Thank you Andy for taking time into this detailed review - catpt now makes use of common linux/pxa2xx_ssp.h header file, removing redundant SSP register declarations in the process. As stated in the opening, this is dependent upon linux-spi change: spi: pxa2xx: Add SSC2 and SSPSP2 SSP registers - updated Kconfig by removing DMADEVICES and adding COMPILE_TEST as optional depends-on - updated all register macros definitions to be more safe against common arithmetics when specifying macro's parameters - removed CONFIG_PM and CONFIG_PM_SLEEP usage in favor of __maybe_unused - all 'if (ret < 0)' converted to simple 'if (ret)' whenever possible - fixed erroneous check for platform_device_register_data within catpt_register_board() - _SLAVE/_MASTER replaced with more inclusive _CONSUMER/_PROVIDER for enum catpt_ssp_mode - catpt_acpi_probe() is now making use of high-level wrappers for ioremapping and resource assignment, reducing function's code size - due to improved catpt_acpi_probe() behavior, catpt_acpi_remove() needs not to cast dma_free_coherent() any longer - DMA source and destrination maxburst now of value 16, see: https://www.spinics.net/lists/alsa-devel/msg114394.html - simplified catpt_dsp_update_lpclock() as list_for_each_entry() is empty-safe by default - dropped '_SSP_' from all names of all CATPT_SSP_SSXXX_DEFAULT macros - catpt_updatel_pci now makes use of linux/pci.h and uapi/linux/pci.h constants such as: PCI_PM_CTRL_STATE_MASK and PCI_D3hot Changes in v4: https://www.spinics.net/lists/alsa-devel/msg113762.html - fixed compilation with i386 kconfig (conflicting names) - streamlined naming for SHIM and PCI registers to match SSP ones (SHIM_REG -> SHIM) - catpt_component_probe removed and kcontrols again initializzed statically via snd_kcontrol_new array: this is to remove kctl->id.device shenanigans - renamed catpt_set_ctlvol to catpt_set_dspvol - function name wasn't matching its purpose Changes in v3: - fixed IRAM mask usage in lpt_dsp_power_up (dsp.c) - updated dbg message formatting in catpt_restore_fwimage as suggested by Andy - fixed alignment for struct catpt_ssp_device_format - catpt_set_ctlvol now verifies all-equal scenario based on all channels rather than just first two as requested by Amadeo - fixed SPDX for registers.h Changes in v2: https://www.spinics.net/lists/alsa-devel/msg113660.html - fixed SPDX formatting for all header files as well as pcm.c - fixed size provided to memcpy() in fw_build_read() as reported by Mark - renamed struct catpt_pdata to struct catpt_spec (cosmetic) - fixed erroneous path in catpt_load_block: region is properly released - trace.h events for updating registers have been removed and usages replaced by dev_dbg (SRAMPGE/ LPCS) - as requested by Andy, struct resource has replaced struct catpt_mbank and struct catpt_mregion. This change cascaded into: - catpt_mbank_size and catpt_mregion_size replaced by resource_size - catpt_mregion_intersects replaced by resource_overlaps - all catpt_mbank_ and catpt_mregion_ handlers found in loader.c (_request, _reserve, _release, _extract, _split, _join) have been removed - __request_region and __release_region have been enlisted in their place - catpt_mregion_intersecting renamed to catpt_resource_overlapping - catpt_request_region helper has been provided to deal with -size based requests o haven't found direct replacements in resource.c/ ioport.h for both functions - catpt_mbank_create and catpt_mbank_remove renamed to catpt_sram_init and catpt_sram_free respectively - catpt_sram_init now returns void instead of int and has been converted to simple initialized. This change ultimately cascaded into: o both SRAM banks initialization being moved to catpt_dev_init from catpt_acpi_probe (device.c) o catpt_dev::spec is now initialized first, with catpt_dev_init following it soon after o catpt_acpi_probe erroneous path has been simplified as SRAM banks no longer need to be freed - catpt_sram_free now frees all resources via child -> sibling enumeration rather than region_list iteration - catpt_dsp_update_srampge and catpt_dsp_set_srampge now accept new argument: unsigned long mask. Caused by removal of catpt_mbank - mask is taken directly from catpt_dev::spec::d/iram_mask - trace.h events for catpt_mbank and catpt_mregion have been removed Diff against last drop on internal list: https://www.spinics.net/lists/alsa-devel/msg113549.html - replaced spinlock with mutex for mregion allocation and release to address sleeping in atomic context warnings - fixed coredump fw_hash dumping - kcontrol values are now always stored regardless of stream of interest is running or not - kcontrol values are now applied after stream is prepared instead of ignoring what has been set by user initially - catpt_pdata instances have been renamed from hsw_ and bdw_ to lpt_ and wpt_ respectively - reordered Makefile .o(s) (cosmetic) Cezary Rojewski (14): ASoC: Intel: Add catpt base members ASoC: Intel: catpt: Implement IPC protocol ASoC: Intel: catpt: Add IPC message handlers ASoC: Intel: catpt: Define DSP operations ASoC: Intel: catpt: Firmware loading and context restore ASoC: Intel: catpt: PCM operations ASoC: Intel: catpt: Device driver lifecycle ASoC: Intel: catpt: Event tracing ASoC: Intel: catpt: Simple sysfs attributes ASoC: Intel: haswell: Remove haswell-solution specific code ASoC: Intel: broadwell: Remove haswell-solution specific code ASoC: Intel: bdw-5650: Remove haswell-solution specific code ASoC: Intel: bdw-5677: Remove haswell-solution specific code ASoC: Intel: Select catpt and deprecate haswell .../ABI/testing/sysfs-bus-pci-devices-catpt | 16 + sound/soc/intel/Kconfig | 24 +- sound/soc/intel/Makefile | 2 +- sound/soc/intel/boards/Kconfig | 8 +- sound/soc/intel/boards/bdw-rt5650.c | 36 - sound/soc/intel/boards/bdw-rt5677.c | 33 - sound/soc/intel/boards/broadwell.c | 33 - sound/soc/intel/boards/haswell.c | 28 +- sound/soc/intel/catpt/Makefile | 6 + sound/soc/intel/catpt/core.h | 188 +++ sound/soc/intel/catpt/device.c | 352 +++++ sound/soc/intel/catpt/dsp.c | 578 ++++++++ sound/soc/intel/catpt/ipc.c | 298 +++++ sound/soc/intel/catpt/loader.c | 671 ++++++++++ sound/soc/intel/catpt/messages.c | 313 +++++ sound/soc/intel/catpt/messages.h | 401 ++++++ sound/soc/intel/catpt/pcm.c | 1175 +++++++++++++++++ sound/soc/intel/catpt/registers.h | 178 +++ sound/soc/intel/catpt/sysfs.c | 55 + sound/soc/intel/catpt/trace.h | 83 ++ 20 files changed, 4335 insertions(+), 143 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-catpt create mode 100644 sound/soc/intel/catpt/Makefile create mode 100644 sound/soc/intel/catpt/core.h create mode 100644 sound/soc/intel/catpt/device.c create mode 100644 sound/soc/intel/catpt/dsp.c create mode 100644 sound/soc/intel/catpt/ipc.c create mode 100644 sound/soc/intel/catpt/loader.c create mode 100644 sound/soc/intel/catpt/messages.c create mode 100644 sound/soc/intel/catpt/messages.h create mode 100644 sound/soc/intel/catpt/pcm.c create mode 100644 sound/soc/intel/catpt/registers.h create mode 100644 sound/soc/intel/catpt/sysfs.c create mode 100644 sound/soc/intel/catpt/trace.h -- 2.17.1

4 20

[PATCH] ASoC: wm8523: Fix a typo in a comment
by Christophe JAILLET 02 Oct '20

02 Oct '20

It is likely that this header file is about the WM8523. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- sound/soc/codecs/wm8523.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm8523.h b/sound/soc/codecs/wm8523.h index 79afbf1e4f1a..5f9bb3df1866 100644 --- a/sound/soc/codecs/wm8523.h +++ b/sound/soc/codecs/wm8523.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0-only */ /* - * wm8523.h -- WM8423 ASoC driver + * wm8523.h -- WM8523 ASoC driver * * Copyright 2009 Wolfson Microelectronics, plc * -- 2.25.1

2 1

[PATCH] ALSA: hda/realtek - Add mute Led support for HP Elitebook 845 G7
by Qiu Wenbo 02 Oct '20

02 Oct '20

After installing archlinux, the mute led and micmute led are not working at all. This patch fix this issue by applying a fixup from similar model. These mute leds are confirmed working on HP Elitebook 845 G7. Signed-off-by: Qiu Wenbo <qiuwenbo(a)kylinos.com.cn> --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index d4f17b465892..8239c4dd4a90 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -7763,6 +7763,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x869d, "HP", ALC236_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x8729, "HP", ALC285_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8736, "HP", ALC285_FIXUP_HP_GPIO_AMP_INIT), + SND_PCI_QUIRK(0x103c, 0x8760, "HP", ALC285_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x877a, "HP", ALC285_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x877d, "HP", ALC236_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC), -- 2.28.0

2 1

[PATCH 1/2] dt-bindings: tas2764: Add the TAS2764 binding doc
by Dan Murphy 02 Oct '20

02 Oct '20

Add the binding for the TAS2764 Smart Amplifier. Signed-off-by: Dan Murphy <dmurphy(a)ti.com> --- .../devicetree/bindings/sound/tas2764.yaml | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tas2764.yaml diff --git a/Documentation/devicetree/bindings/sound/tas2764.yaml b/Documentation/devicetree/bindings/sound/tas2764.yaml new file mode 100644 index 000000000000..4e758ff81003 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tas2764.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/tas2764.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Texas Instruments TAS2764 Smart PA + +maintainers: + - Dan Murphy <dmurphy(a)ti.com> + +description: | + The TAS2764 is a mono, digital input Class-D audio amplifier optimized for + efficiently driving high peak power into small loudspeakers. + Integrated speaker voltage and current sense provides for + real time monitoring of loudspeaker behavior. + +properties: + compatible: + enum: + - ti,tas2764 + + reg: + maxItems: 1 + description: | + I2C address of the device can be between 0x38 to 0x45. + + reset-gpio: + description: GPIO used to reset the device. + + shutdown-gpios: + description: GPIO used to control the state of the device. + + interrupts: + maxItems: 1 + + ti,imon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX current sense time slot. + + ti,vmon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX voltage sense time slot. + + '#sound-dai-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + codec: codec@38 { + compatible = "ti,tas2764"; + reg = <0x38>; + #sound-dai-cells = <1>; + interrupt-parent = <&gpio1>; + interrupts = <14>; + reset-gpio = <&gpio1 15 0>; + shutdown-gpios = <&gpio1 15 0>; + ti,imon-slot-no = <0>; + ti,vmon-slot-no = <2>; + }; + }; + +... -- 2.28.0.585.ge1cfff676549

2 4

[alsa-devel] [PATCH] ALSA: usb-audio: fix spelling mistake "Frequence" -> "Frequency"
by Colin King 02 Oct '20

02 Oct '20

From: Colin Ian King <colin.king(a)canonical.com> There are spelling mistakes in equalizer name fields, fix them. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/usb/mixer_us16x08.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/usb/mixer_us16x08.c b/sound/usb/mixer_us16x08.c index 26ed23b18b77..4f594f9552a8 100644 --- a/sound/usb/mixer_us16x08.c +++ b/sound/usb/mixer_us16x08.c @@ -1119,7 +1119,7 @@ static const struct snd_us16x08_control_params eq_controls[] = { .control_id = SND_US16X08_ID_EQLOWFREQ, .type = USB_MIXER_U8, .num_channels = 16, - .name = "EQ Low Frequence", + .name = "EQ Low Frequency", }, { /* EQ mid low gain */ .kcontrol_new = &snd_us16x08_eq_gain_ctl, @@ -1133,7 +1133,7 @@ static const struct snd_us16x08_control_params eq_controls[] = { .control_id = SND_US16X08_ID_EQLOWMIDFREQ, .type = USB_MIXER_U8, .num_channels = 16, - .name = "EQ MidLow Frequence", + .name = "EQ MidLow Frequency", }, { /* EQ mid low Q */ .kcontrol_new = &snd_us16x08_eq_mid_width_ctl, @@ -1154,7 +1154,7 @@ static const struct snd_us16x08_control_params eq_controls[] = { .control_id = SND_US16X08_ID_EQHIGHMIDFREQ, .type = USB_MIXER_U8, .num_channels = 16, - .name = "EQ MidHigh Frequence", + .name = "EQ MidHigh Frequency", }, { /* EQ mid high Q */ .kcontrol_new = &snd_us16x08_eq_mid_width_ctl, @@ -1175,7 +1175,7 @@ static const struct snd_us16x08_control_params eq_controls[] = { .control_id = SND_US16X08_ID_EQHIGHFREQ, .type = USB_MIXER_U8, .num_channels = 16, - .name = "EQ High Frequence", + .name = "EQ High Frequency", }, }; -- 2.19.1

3 3

alsactl: init - add -U option to disable UCM based init
by GitHub pull_request - edited 02 Oct '20

02 Oct '20

alsa-project/alsa-utils pull request #60 was edited from ahlinc: The reason is to use it with internal init extra commands like: alsactl -U -E CMD=info init Currently, if there is a valid UCM config for a card the alsactl command exits silently on the init command and don't execute any extra commands because that commands defined in a common init path file _init/00main_ that don't used in case of UCM did the job. Request URL : https://github.com/alsa-project/alsa-utils/pull/60 Patch URL : https://github.com/alsa-project/alsa-utils/pull/60.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

alsactl: init - add -U option to disable UCM based init
by GitHub pull_request - opened 02 Oct '20

02 Oct '20

alsa-project/alsa-utils pull request #60 was opened from ahlinc: The reason is to use it with internal init extra commands like: alsactl -U -E CMD=info init Currently, if there is a valid UCM config for a card the alsactl command exits silently on the init command and don't execute any extra commands because that commands defined in common init path file _init/00main_ that don't used in case of UCM did the job. Request URL : https://github.com/alsa-project/alsa-utils/pull/60 Patch URL : https://github.com/alsa-project/alsa-utils/pull/60.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH] ASoC: soc-pcm: ignore un-needed mutex_unlock() case on soc_pcm_open()
by Kuninori Morimoto 02 Oct '20

02 Oct '20

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> commit 140a4532cdb8c ("ASoC: soc-pcm: add soc_pcm_clean() and call it from soc_pcm_open/close()") switch to call soc_pcm_clean() on soc_pcm_open() when rollback case. But, it uses "goto err" (A) *before* mutex_lock() (B) when error of snd_soc_pcm_component_pm_runtime_get(). The mutex_unlock() (C) is not needed in such case. This patch fix it. static int soc_pcm_open(...) { ... ret = snd_soc_pcm_component_pm_runtime_get(rtd, substream); if (ret < 0) (A) goto err; (B) mutex_lock_nested(...); ... err: (C) mutex_unlock(..); ... } Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/soc-pcm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 09e8d703a502..5d538520e2cf 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -706,7 +706,7 @@ static int soc_pcm_open(struct snd_pcm_substream *substream) ret = snd_soc_pcm_component_pm_runtime_get(rtd, substream); if (ret < 0) - goto err; + goto pm_err; mutex_lock_nested(&rtd->card->pcm_mutex, rtd->card->pcm_subclass); @@ -786,7 +786,7 @@ static int soc_pcm_open(struct snd_pcm_substream *substream) snd_soc_runtime_activate(rtd, substream->stream); err: mutex_unlock(&rtd->card->pcm_mutex); - +pm_err: if (ret < 0) soc_pcm_clean(substream, 1); -- 2.25.1

2 1

[PATCH -next] ASoC: tegra: tegra_wm8753: use devm_snd_soc_register_card()
by Qinglang Miao 02 Oct '20

02 Oct '20

Using devm_snd_soc_register_card() can make the code shorter and cleaner. Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> --- sound/soc/tegra/tegra_wm8753.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/sound/soc/tegra/tegra_wm8753.c b/sound/soc/tegra/tegra_wm8753.c index ec3ee0580..fa41fa366 100644 --- a/sound/soc/tegra/tegra_wm8753.c +++ b/sound/soc/tegra/tegra_wm8753.c @@ -155,7 +155,7 @@ static int tegra_wm8753_driver_probe(struct platform_device *pdev) if (ret) return ret; - ret = snd_soc_register_card(card); + ret = devm_snd_soc_register_card(&pdev->dev, card); if (ret) { dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret); @@ -165,15 +165,6 @@ static int tegra_wm8753_driver_probe(struct platform_device *pdev) return 0; } -static int tegra_wm8753_driver_remove(struct platform_device *pdev) -{ - struct snd_soc_card *card = platform_get_drvdata(pdev); - - snd_soc_unregister_card(card); - - return 0; -} - static const struct of_device_id tegra_wm8753_of_match[] = { { .compatible = "nvidia,tegra-audio-wm8753", }, {}, @@ -186,7 +177,6 @@ static struct platform_driver tegra_wm8753_driver = { .of_match_table = tegra_wm8753_of_match, }, .probe = tegra_wm8753_driver_probe, - .remove = tegra_wm8753_driver_remove, }; module_platform_driver(tegra_wm8753_driver); -- 2.23.0

2 1

[PATCH -next] ASoC: tegra: tegra_max98090: use devm_snd_soc_register_card()
by Qinglang Miao 02 Oct '20

02 Oct '20

Using devm_snd_soc_register_card() can make the code shorter and cleaner. Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> --- sound/soc/tegra/tegra_max98090.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/sound/soc/tegra/tegra_max98090.c b/sound/soc/tegra/tegra_max98090.c index af3e9e6da..9d8e16473 100644 --- a/sound/soc/tegra/tegra_max98090.c +++ b/sound/soc/tegra/tegra_max98090.c @@ -246,7 +246,7 @@ static int tegra_max98090_probe(struct platform_device *pdev) if (ret) return ret; - ret = snd_soc_register_card(card); + ret = devm_snd_soc_register_card(&pdev->dev, card); if (ret) { dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret); @@ -256,15 +256,6 @@ static int tegra_max98090_probe(struct platform_device *pdev) return 0; } -static int tegra_max98090_remove(struct platform_device *pdev) -{ - struct snd_soc_card *card = platform_get_drvdata(pdev); - - snd_soc_unregister_card(card); - - return 0; -} - static const struct of_device_id tegra_max98090_of_match[] = { { .compatible = "nvidia,tegra-audio-max98090", }, {}, @@ -277,7 +268,6 @@ static struct platform_driver tegra_max98090_driver = { .of_match_table = tegra_max98090_of_match, }, .probe = tegra_max98090_probe, - .remove = tegra_max98090_remove, }; module_platform_driver(tegra_max98090_driver); -- 2.23.0

2 1

[PATCH -next] ASoC: tegra: trimslice.c: use devm_snd_soc_register_card()
by Qinglang Miao 02 Oct '20

02 Oct '20

Using devm_snd_soc_register_card() can make the code shorter and cleaner. Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> --- sound/soc/tegra/trimslice.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/sound/soc/tegra/trimslice.c b/sound/soc/tegra/trimslice.c index cdb386d6e..baae4cce7 100644 --- a/sound/soc/tegra/trimslice.c +++ b/sound/soc/tegra/trimslice.c @@ -143,7 +143,7 @@ static int tegra_snd_trimslice_probe(struct platform_device *pdev) if (ret) return ret; - ret = snd_soc_register_card(card); + ret = devm_snd_soc_register_card(&pdev->dev, card); if (ret) { dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret); @@ -153,15 +153,6 @@ static int tegra_snd_trimslice_probe(struct platform_device *pdev) return 0; } -static int tegra_snd_trimslice_remove(struct platform_device *pdev) -{ - struct snd_soc_card *card = platform_get_drvdata(pdev); - - snd_soc_unregister_card(card); - - return 0; -} - static const struct of_device_id trimslice_of_match[] = { { .compatible = "nvidia,tegra-audio-trimslice", }, {}, @@ -174,7 +165,6 @@ static struct platform_driver tegra_snd_trimslice_driver = { .of_match_table = trimslice_of_match, }, .probe = tegra_snd_trimslice_probe, - .remove = tegra_snd_trimslice_remove, }; module_platform_driver(tegra_snd_trimslice_driver); -- 2.23.0

2 1

[PATCH] ASoC: wm_adsp: Pass full name to snd_ctl_notify
by Charles Keepax 02 Oct '20

02 Oct '20

From: Adam Brickman <Adam.Brickman(a)cirrus.com> A call to wm_adsp_write_ctl() could cause a kernel crash if it does not retrieve a valid kcontrol from snd_soc_card_get_kcontrol(). This can happen due to a missing control name prefix. Then, snd_ctl_notify() crashes when it tries to use the id field. Modified wm_adsp_write_ctl() to incorporate the name_prefix (if applicable) such that it is able to retrieve a valid id field from the kcontrol once the platform has booted. Fixes: eb65ccdb0836 ("ASoC: wm_adsp: Expose mixer control API") Signed-off-by: Adam Brickman <Adam.Brickman(a)cirrus.com> Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> --- sound/soc/codecs/wm_adsp.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c index 410cca57da52d..344bd2c33bea1 100644 --- a/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wm_adsp.c @@ -2049,6 +2049,7 @@ int wm_adsp_write_ctl(struct wm_adsp *dsp, const char *name, int type, { struct wm_coeff_ctl *ctl; struct snd_kcontrol *kcontrol; + char ctl_name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN]; int ret; ctl = wm_adsp_get_ctl(dsp, name, type, alg); @@ -2059,8 +2060,25 @@ int wm_adsp_write_ctl(struct wm_adsp *dsp, const char *name, int type, return -EINVAL; ret = wm_coeff_write_ctrl(ctl, buf, len); + if (ret) + return ret; + + if (ctl->flags & WMFW_CTL_FLAG_SYS) + return 0; + + if (dsp->component->name_prefix) + snprintf(ctl_name, SNDRV_CTL_ELEM_ID_NAME_MAXLEN, "%s %s", + dsp->component->name_prefix, ctl->name); + else + snprintf(ctl_name, SNDRV_CTL_ELEM_ID_NAME_MAXLEN, "%s", + ctl->name); + + kcontrol = snd_soc_card_get_kcontrol(dsp->component->card, ctl_name); + if (!kcontrol) { + adsp_err(dsp, "Can't find kcontrol %s\n", ctl_name); + return -EINVAL; + } - kcontrol = snd_soc_card_get_kcontrol(dsp->component->card, ctl->name); snd_ctl_notify(dsp->component->card->snd_card, SNDRV_CTL_EVENT_MASK_VALUE, &kcontrol->id); -- 2.11.0

2 1

[PATCH 1/3] dt-bindings: sound: Remove unused 'linux,hdmi-audio'
by Rob Herring 02 Oct '20

02 Oct '20

The binding was added in 2013 and has had no driver since 2015. Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Rob Herring <robh(a)kernel.org> --- Documentation/devicetree/bindings/sound/hdmi.txt | 16 ---------------- 1 file changed, 16 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/hdmi.txt diff --git a/Documentation/devicetree/bindings/sound/hdmi.txt b/Documentation/devicetree/bindings/sound/hdmi.txt deleted file mode 100644 index 56407c30e954..000000000000 --- a/Documentation/devicetree/bindings/sound/hdmi.txt +++ /dev/null @@ -1,16 +0,0 @@ -Device-Tree bindings for dummy HDMI codec - -Required properties: - - compatible: should be "linux,hdmi-audio". - -CODEC output pins: - * TX - -CODEC input pins: - * RX - -Example node: - - hdmi_audio: hdmi_audio@0 { - compatible = "linux,hdmi-audio"; - }; -- 2.25.1

2 3

[PATCH] ASoC: soc-pcm: add missing ret=0 at soc_pcm_open()
by Kuninori Morimoto 02 Oct '20

02 Oct '20

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> commit 140a4532cdb8c ("ASoC: soc-pcm: add soc_pcm_clean() and call it from soc_pcm_open/close()") switched to use soc_pcm_clean() at soc_pcm_open(). But it removed "return 0", and missing "ret = 0", because of it, it always return -EINVAL eventhough no error. This patch adds missing "ret = 0" for success case. Reported-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/soc-pcm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 9d3460c19353..03fc9119151c 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -796,6 +796,7 @@ static int soc_pcm_open(struct snd_pcm_substream *substream) runtime->hw.rate_max); dynamic: snd_soc_runtime_activate(rtd, substream->stream); + ret = 0; err: mutex_unlock(&rtd->card->pcm_mutex); pm_err: -- 2.25.1

3 4

[PATCH -next] ASoC: tegra: tegra_rt5640: use devm_snd_soc_register_card()
by Qinglang Miao 02 Oct '20

02 Oct '20

Using devm_snd_soc_register_card() can make the code shorter and cleaner. Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> --- sound/soc/tegra/tegra_rt5640.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/sound/soc/tegra/tegra_rt5640.c b/sound/soc/tegra/tegra_rt5640.c index d66d86593..c73bd23b3 100644 --- a/sound/soc/tegra/tegra_rt5640.c +++ b/sound/soc/tegra/tegra_rt5640.c @@ -192,7 +192,7 @@ static int tegra_rt5640_probe(struct platform_device *pdev) if (ret) return ret; - ret = snd_soc_register_card(card); + ret = devm_snd_soc_register_card(&pdev->dev, card); if (ret) { dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret); @@ -202,15 +202,6 @@ static int tegra_rt5640_probe(struct platform_device *pdev) return 0; } -static int tegra_rt5640_remove(struct platform_device *pdev) -{ - struct snd_soc_card *card = platform_get_drvdata(pdev); - - snd_soc_unregister_card(card); - - return 0; -} - static const struct of_device_id tegra_rt5640_of_match[] = { { .compatible = "nvidia,tegra-audio-rt5640", }, {}, @@ -223,7 +214,6 @@ static struct platform_driver tegra_rt5640_driver = { .of_match_table = tegra_rt5640_of_match, }, .probe = tegra_rt5640_probe, - .remove = tegra_rt5640_remove, }; module_platform_driver(tegra_rt5640_driver); -- 2.23.0

2 1

[PATCH -next] ASoC: fsl: mx27vis-aic32x4: use devm_snd_soc_register_card()
by Qinglang Miao 02 Oct '20

02 Oct '20

Using devm_snd_soc_register_card() can make the code shorter and cleaner. Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> --- sound/soc/fsl/mx27vis-aic32x4.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/sound/soc/fsl/mx27vis-aic32x4.c b/sound/soc/fsl/mx27vis-aic32x4.c index 4ead537e0..8d3b18973 100644 --- a/sound/soc/fsl/mx27vis-aic32x4.c +++ b/sound/soc/fsl/mx27vis-aic32x4.c @@ -176,7 +176,7 @@ static int mx27vis_aic32x4_probe(struct platform_device *pdev) mx27vis_amp_muter_gpio = pdata->amp_muter_gpio; mx27vis_aic32x4.dev = &pdev->dev; - ret = snd_soc_register_card(&mx27vis_aic32x4); + ret = devm_snd_soc_register_card(&pdev->dev, &mx27vis_aic32x4); if (ret) { dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret); @@ -199,19 +199,11 @@ static int mx27vis_aic32x4_probe(struct platform_device *pdev) return ret; } -static int mx27vis_aic32x4_remove(struct platform_device *pdev) -{ - snd_soc_unregister_card(&mx27vis_aic32x4); - - return 0; -} - static struct platform_driver mx27vis_aic32x4_audio_driver = { .driver = { .name = "mx27vis", }, .probe = mx27vis_aic32x4_probe, - .remove = mx27vis_aic32x4_remove, }; module_platform_driver(mx27vis_aic32x4_audio_driver); -- 2.23.0

2 1

[PATCH] ASoC: fsl_spdif: Fix unnecessary check in fsl_spdif_probe()
by Tang Bin 02 Oct '20

02 Oct '20

The function fsl_spdif_probe() is only called with an openfirmware platform device. Therefore there is no need to check that the passed in device is NULL. Signed-off-by: Zhang Shengju <zhangshengju(a)cmss.chinamobile.com> Signed-off-by: Tang Bin <tangbin(a)cmss.chinamobile.com> --- sound/soc/fsl/fsl_spdif.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c index 7858a5499..395c50167 100644 --- a/sound/soc/fsl/fsl_spdif.c +++ b/sound/soc/fsl/fsl_spdif.c @@ -1221,9 +1221,6 @@ static int fsl_spdif_probe(struct platform_device *pdev) void __iomem *regs; int irq, ret, i; - if (!np) - return -ENODEV; - spdif_priv = devm_kzalloc(&pdev->dev, sizeof(*spdif_priv), GFP_KERNEL); if (!spdif_priv) return -ENOMEM; -- 2.20.1.windows.1

2 3

[PATCH -next] ASoC: fsl: imx-mc13783: use devm_snd_soc_register_card()
by Qinglang Miao 02 Oct '20

02 Oct '20

Using devm_snd_soc_register_card() can make the code shorter and cleaner. Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> --- sound/soc/fsl/imx-mc13783.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/sound/soc/fsl/imx-mc13783.c b/sound/soc/fsl/imx-mc13783.c index dd9c1ac81..d9dca7bbc 100644 --- a/sound/soc/fsl/imx-mc13783.c +++ b/sound/soc/fsl/imx-mc13783.c @@ -96,7 +96,7 @@ static int imx_mc13783_probe(struct platform_device *pdev) imx_mc13783.dev = &pdev->dev; - ret = snd_soc_register_card(&imx_mc13783); + ret = devm_snd_soc_register_card(&pdev->dev, &imx_mc13783); if (ret) { dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret); @@ -140,19 +140,11 @@ static int imx_mc13783_probe(struct platform_device *pdev) return ret; } -static int imx_mc13783_remove(struct platform_device *pdev) -{ - snd_soc_unregister_card(&imx_mc13783); - - return 0; -} - static struct platform_driver imx_mc13783_audio_driver = { .driver = { .name = "imx_mc13783", }, .probe = imx_mc13783_probe, - .remove = imx_mc13783_remove }; module_platform_driver(imx_mc13783_audio_driver); -- 2.23.0

2 1

Webcam Microphone not working
by Adam Baker 02 Oct '20

02 Oct '20

Hi, I've recently acquired a couple of different cheap webcams and on both of them the microphone is not working under Linux but works under Windows. Both cameras appear to use the same chip ID 1b3f:2002 Generalplus Technology Inc. 808 Camera which on one endpoint provides a UAC V1 audio signal. Comparing wireshark USB captures between Windows and Linux I saw that windows is using much larger URBs than Linux so as a quick hack added to endpoint.c +++ sound/usb/endpoint.c 2020-10-01 22:46:30.191648731 +0100 @@ -687,6 +687,10 @@ static int data_ep_set_params(struct snd ep->freqmax = (data_maxsize / (frame_bits >> 3)) << (16 - ep->datainterval); } + if (maxsize < 128) + maxsize = 128; + dev_info(&ep->chip->dev->dev, "max: %d, epmax : %d, frq: %d\n", + maxsize, ep->maxpacksize, ep->freqmax); if (ep->fill_max) ep->curpacksize = ep->maxpacksize; This was enough to make the microphone work suggesting that I am at least looking in the right area. The code in endpoint.c appears to be attempting to optimise the size of the URB based upon the sample frequency, sample size and the maximum rate at which packets can be sent in order to minimise latency and allow accurate start / stop timing. Looking at the packet capture however I suspect that that calculation is failing to account for some fixed header sizes. Before I delve into understanding this code and isochronous USB better I'd like to know if anyone has quick answers to the following questions: 1) Has this already been addressed in a newer kernel, I'm currently using Debian 4.19 because that is where I first found the problem? 2) What is the preferred kernel against which patches to this subsystem should be provided, is it the latest released kernel on Linus' git tree, the latest RC or a subsystem tree? 3) The sellers of these cameras both claimed they work under Linux. Do I need to try to find if there was a time in the past when they did work and if so provide a fixes tag against the commit that broke support? Would doing so affect the chances of a fixes making it to stable kernels? 4) Is there any documentation other than code comments indicating how the URB size calculation is supposed to work that I should read? 5) Are there any specific gotchas in this driver that I should be aware of? Thanks Adam Baker P.S. I do realise that once I have a properly tested patch you will want to see it sent with git-send-email and a signed off by line.

1 0

[PATCH] ALSA: compress: allow pause and resume during draining
by Gyeongtaek Lee 01 Oct '20

01 Oct '20

With a stream with low bitrate, user can't pause or resume the stream near the end of the stream because current ALSA doesn't allow it. If the stream has very low bitrate enough to store whole stream into the buffer, user can't do anything except stop the stream and then restart it from the first. If pause and resume is allowed during draining, user experience can be enhanced. Signed-off-by: Gyeongtaek Lee <gt82.lee(a)samsung.com> --- sound/core/compress_offload.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c index 0e53f6f31916..90b437f302a0 100644 --- a/sound/core/compress_offload.c +++ b/sound/core/compress_offload.c @@ -708,11 +708,20 @@ static int snd_compr_pause(struct snd_compr_stream *stream) { int retval; - if (stream->runtime->state != SNDRV_PCM_STATE_RUNNING) + switch (stream->runtime->state) { + case SNDRV_PCM_STATE_RUNNING: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_PUSH); + if (!retval) + stream->runtime->state = SNDRV_PCM_STATE_PAUSED; + break; + case SNDRV_PCM_STATE_DRAINING: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_PUSH); + break; + default: return -EPERM; - retval = stream->ops->trigger(stream, SNDRV_PCM_TRIGGER_PAUSE_PUSH); - if (!retval) - stream->runtime->state = SNDRV_PCM_STATE_PAUSED; + } return retval; } @@ -720,11 +729,20 @@ static int snd_compr_resume(struct snd_compr_stream *stream) { int retval; - if (stream->runtime->state != SNDRV_PCM_STATE_PAUSED) + switch (stream->runtime->state) { + case SNDRV_PCM_STATE_PAUSED: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_RELEASE); + if (!retval) + stream->runtime->state = SNDRV_PCM_STATE_RUNNING; + break; + case SNDRV_PCM_STATE_DRAINING: + retval = stream->ops->trigger(stream, + SNDRV_PCM_TRIGGER_PAUSE_RELEASE); + break; + default: return -EPERM; - retval = stream->ops->trigger(stream, SNDRV_PCM_TRIGGER_PAUSE_RELEASE); - if (!retval) - stream->runtime->state = SNDRV_PCM_STATE_RUNNING; + } return retval; } base-commit: a1b8638ba1320e6684aa98233c15255eb803fac7 -- 2.21.0

5 10

unable to initialize sum ring buffer error
by GitHub issues - edited 01 Oct '20

01 Oct '20

alsa-project/alsa-lib issue #83 was edited from Komal1809: i am using alsa-lib-1.1.4.1 library version. Whenever trying to play audio from file using aplay getting error as alsa-lib-1.1.4.1/src/pcm/pcm_dmix.c:1177: **(snd_pcm_dmix_open) unable to initialize sum ring buffer** Note : audio is getting played at the start once system reboot Please let me know how to debug this issue Issue URL : https://github.com/alsa-project/alsa-lib/issues/83 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

unable to initialize sum ring buffer error
by GitHub issues - opened 01 Oct '20

01 Oct '20

alsa-project/alsa-lib issue #83 was opened from Komal1809: i am using alsa-lib-1.1.4.1 library version. Whenever trying to play audio from file using aplay getting error as alsa-lib-1.1.4.1/src/pcm/pcm_dmix.c:1177: **(snd_pcm_dmix_open) unable to initialize sum ring buffer** Note : audio is getting played at the start once system reboot Issue URL : https://github.com/alsa-project/alsa-lib/issues/83 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH v2 0/7][RESEND] ASoC: merge soc_pcm_open() rollback and soc_pcm_close()
by Kuninori Morimoto 01 Oct '20

01 Oct '20

Hi Mark 1 month past and nothing happened. This is resend of v2 patch-set. soc_pcm_open() does rollback when failed (A), but, it is almost same as soc_pcm_close(). static int soc_pcm_open(xxx) { ... if (ret < 0) goto xxx_err; ... return 0; ^ config_err: | ... | rtd_startup_err: (A) ... | component_err: | ... v return ret; } This kind of duplicated code can be a hotbed of bugs, thus, this patch-set share soc_pcm_close() and rollback. v1 -> v2 - indicate more detail background/logic on git-log Link: https://lore.kernel.org/r/87wo2oku0m.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87wo1kvozz.wl-kuninori.morimoto.gx@renesas.com Kuninori Morimoto (7): ASoC: soc-dai: add mark for snd_soc_dai_startup/shutdown() ASoC: soc-link: add mark for snd_soc_link_startup/shutdown() ASoC: soc-component: add mark for soc_pcm_components_open/close() ASoC: soc-component: add mark for snd_soc_pcm_component_pm_runtime_get/put() ASoC: soc-pcm: add soc_pcm_clean() and call it from soc_pcm_open/close() ASoC: soc-pcm: remove unneeded dev_err() for snd_soc_dai_startup() ASoC: soc-pcm: remove unneeded dev_err() for snd_soc_component_module/open() include/sound/soc-component.h | 28 +++++--- include/sound/soc-dai.h | 5 +- include/sound/soc-link.h | 3 +- include/sound/soc.h | 3 + sound/soc/soc-component.c | 73 ++++++++++++++++++++- sound/soc/soc-compress.c | 30 +++------ sound/soc/soc-dai.c | 21 +++++- sound/soc/soc-dapm.c | 4 +- sound/soc/soc-link.c | 21 +++++- sound/soc/soc-pcm.c | 120 ++++++++++++---------------------- 10 files changed, 190 insertions(+), 118 deletions(-) -- 2.25.1

3 11

[PATCH v4 22/52] docs: get rid of :c:type explicit declarations for structs
by Mauro Carvalho Chehab 30 Sep '20

30 Sep '20

The :c:type:`foo` only works properly with structs before Sphinx 3.x. On Sphinx 3.x, structs should now be declared using the .. c:struct, and referenced via :c:struct tag. As we now have the automarkup.py macro, that automatically convert: struct foo into cross-references, let's get rid of that, solving several warnings when building docs with Sphinx 3.x. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- Documentation/block/blk-mq.rst | 8 +++---- Documentation/block/inline-encryption.rst | 8 +++---- Documentation/driver-api/fpga/fpga-bridge.rst | 4 ++-- Documentation/driver-api/fpga/fpga-mgr.rst | 4 ++-- Documentation/driver-api/fpga/fpga-region.rst | 2 +- Documentation/driver-api/iio/buffers.rst | 2 +- Documentation/driver-api/iio/core.rst | 6 ++--- Documentation/driver-api/iio/hw-consumer.rst | 2 +- .../driver-api/iio/triggered-buffers.rst | 2 +- Documentation/driver-api/iio/triggers.rst | 4 ++-- .../driver-api/media/dtv-frontend.rst | 4 ++-- Documentation/driver-api/media/mc-core.rst | 24 +++++++++---------- .../driver-api/media/v4l2-controls.rst | 2 +- Documentation/driver-api/media/v4l2-dev.rst | 8 +++---- .../driver-api/media/v4l2-device.rst | 6 ++--- Documentation/driver-api/media/v4l2-event.rst | 10 ++++---- Documentation/driver-api/media/v4l2-fh.rst | 16 ++++++------- .../driver-api/media/v4l2-subdev.rst | 2 +- Documentation/driver-api/regulator.rst | 4 ++-- Documentation/driver-api/usb/URB.rst | 2 +- Documentation/driver-api/usb/gadget.rst | 10 ++++---- Documentation/driver-api/usb/hotplug.rst | 2 +- Documentation/filesystems/fscrypt.rst | 14 +++++------ Documentation/filesystems/fsverity.rst | 2 +- Documentation/sound/designs/tracepoints.rst | 22 ++++++++--------- Documentation/sphinx/parse-headers.pl | 2 +- Documentation/vm/ksm.rst | 2 +- Documentation/vm/memory-model.rst | 6 ++--- mm/ksm.c | 2 +- mm/memblock.c | 4 ++-- 30 files changed, 93 insertions(+), 93 deletions(-) diff --git a/Documentation/block/blk-mq.rst b/Documentation/block/blk-mq.rst index 88c56afcb070..86a632af02b0 100644 --- a/Documentation/block/blk-mq.rst +++ b/Documentation/block/blk-mq.rst @@ -63,10 +63,10 @@ Software staging queues ~~~~~~~~~~~~~~~~~~~~~~~ The block IO subsystem adds requests in the software staging queues -(represented by struct :c:type:`blk_mq_ctx`) in case that they weren't sent +(represented by struct blk_mq_ctx) in case that they weren't sent directly to the driver. A request is one or more BIOs. They arrived at the -block layer through the data structure struct :c:type:`bio`. The block layer -will then build a new structure from it, the struct :c:type:`request` that will +block layer through the data structure struct bio. The block layer +will then build a new structure from it, the struct request that will be used to communicate with the device driver. Each queue has its own lock and the number of queues is defined by a per-CPU or per-node basis. @@ -102,7 +102,7 @@ hardware queue will be drained in sequence according to their mapping. Hardware dispatch queues ~~~~~~~~~~~~~~~~~~~~~~~~ -The hardware queue (represented by struct :c:type:`blk_mq_hw_ctx`) is a struct +The hardware queue (represented by struct blk_mq_hw_ctx) is a struct used by device drivers to map the device submission queues (or device DMA ring buffer), and are the last step of the block layer submission code before the low level device driver taking ownership of the request. To run this queue, the diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 354817b80887..e75151e467d3 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -52,7 +52,7 @@ Constraints and notes Design ====== -We add a :c:type:`struct bio_crypt_ctx` to :c:type:`struct bio` that can +We add a struct bio_crypt_ctx to struct bio that can represent an encryption context, because we need to be able to pass this encryption context from the upper layers (like the fs layer) to the device driver to act upon. @@ -85,7 +85,7 @@ blk-mq changes, other block layer changes and blk-crypto-fallback ================================================================= We add a pointer to a ``bi_crypt_context`` and ``keyslot`` to -:c:type:`struct request`. These will be referred to as the ``crypto fields`` +struct request. These will be referred to as the ``crypto fields`` for the request. This ``keyslot`` is the keyslot into which the ``bi_crypt_context`` has been programmed in the KSM of the ``request_queue`` that this request is being sent to. @@ -118,7 +118,7 @@ of the algorithm being used adheres to spec and functions correctly). If a ``request queue``'s inline encryption hardware claimed to support the encryption context specified with a bio, then it will not be handled by the ``blk-crypto-fallback``. We will eventually reach a point in blk-mq when a -:c:type:`struct request` needs to be allocated for that bio. At that point, +struct request needs to be allocated for that bio. At that point, blk-mq tries to program the encryption context into the ``request_queue``'s keyslot_manager, and obtain a keyslot, which it stores in its newly added ``keyslot`` field. This keyslot is released when the request is completed. @@ -188,7 +188,7 @@ keyslots supported by the hardware. The device driver also needs to tell the KSM how to actually manipulate the IE hardware in the device to do things like programming the crypto key into the IE hardware into a particular keyslot. All this is achieved through the -:c:type:`struct blk_ksm_ll_ops` field in the KSM that the device driver +struct blk_ksm_ll_ops field in the KSM that the device driver must fill up after initing the ``blk_keyslot_manager``. The KSM also handles runtime power management for the device when applicable diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst index ccd677ba7d76..198aadafd3e7 100644 --- a/Documentation/driver-api/fpga/fpga-bridge.rst +++ b/Documentation/driver-api/fpga/fpga-bridge.rst @@ -4,8 +4,8 @@ FPGA Bridge API to implement a new FPGA bridge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* struct :c:type:`fpga_bridge` — The FPGA Bridge structure -* struct :c:type:`fpga_bridge_ops` — Low level Bridge driver ops +* struct fpga_bridge — The FPGA Bridge structure +* struct fpga_bridge_ops — Low level Bridge driver ops * devm_fpga_bridge_create() — Allocate and init a bridge struct * fpga_bridge_register() — Register a bridge * fpga_bridge_unregister() — Unregister a bridge diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst index af5382af1379..22f7885b32c9 100644 --- a/Documentation/driver-api/fpga/fpga-mgr.rst +++ b/Documentation/driver-api/fpga/fpga-mgr.rst @@ -102,8 +102,8 @@ API for implementing a new FPGA Manager driver ---------------------------------------------- * ``fpga_mgr_states`` — Values for :c:member:`fpga_manager->state`. -* struct :c:type:`fpga_manager` — the FPGA manager struct -* struct :c:type:`fpga_manager_ops` — Low level FPGA manager driver ops +* struct fpga_manager — the FPGA manager struct +* struct fpga_manager_ops — Low level FPGA manager driver ops * devm_fpga_mgr_create() — Allocate and init a manager struct * fpga_mgr_register() — Register an FPGA manager * fpga_mgr_unregister() — Unregister an FPGA manager diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst index 31118a8ba218..3e52be7e2968 100644 --- a/Documentation/driver-api/fpga/fpga-region.rst +++ b/Documentation/driver-api/fpga/fpga-region.rst @@ -45,7 +45,7 @@ An example of usage can be seen in the probe function of [#f2]_. API to add a new FPGA region ---------------------------- -* struct :c:type:`fpga_region` — The FPGA region struct +* struct fpga_region — The FPGA region struct * devm_fpga_region_create() — Allocate and init a region struct * fpga_region_register() — Register an FPGA region * fpga_region_unregister() — Unregister an FPGA region diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst index dd64c9c5fb1e..3ddebddc02ca 100644 --- a/Documentation/driver-api/iio/buffers.rst +++ b/Documentation/driver-api/iio/buffers.rst @@ -2,7 +2,7 @@ Buffers ======= -* struct :c:type:`iio_buffer` — general buffer structure +* struct iio_buffer — general buffer structure * :c:func:`iio_validate_scan_mask_onehot` — Validates that exactly one channel is selected * :c:func:`iio_buffer_get` — Grab a reference to the buffer diff --git a/Documentation/driver-api/iio/core.rst b/Documentation/driver-api/iio/core.rst index 51b21e002396..715cf29482a1 100644 --- a/Documentation/driver-api/iio/core.rst +++ b/Documentation/driver-api/iio/core.rst @@ -10,7 +10,7 @@ applications manipulating sensors. The implementation can be found under Industrial I/O Devices ---------------------- -* struct :c:type:`iio_dev` - industrial I/O device +* struct iio_dev - industrial I/O device * iio_device_alloc() - allocate an :c:type:`iio_dev` from a driver * iio_device_free() - free an :c:type:`iio_dev` from a driver * iio_device_register() - register a device with the IIO subsystem @@ -66,7 +66,7 @@ Common attributes are: IIO device channels =================== -struct :c:type:`iio_chan_spec` - specification of a single channel +struct iio_chan_spec - specification of a single channel An IIO device channel is a representation of a data channel. An IIO device can have one or multiple channels. For example: @@ -77,7 +77,7 @@ have one or multiple channels. For example: * an accelerometer can have up to 3 channels representing acceleration on X, Y and Z axes. -An IIO channel is described by the struct :c:type:`iio_chan_spec`. +An IIO channel is described by the struct iio_chan_spec. A thermometer driver for the temperature sensor in the example above would have to describe its channel as follows:: diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst index 819fb9edc005..76133a3796f2 100644 --- a/Documentation/driver-api/iio/hw-consumer.rst +++ b/Documentation/driver-api/iio/hw-consumer.rst @@ -8,7 +8,7 @@ software buffer for data. The implementation can be found under :file:`drivers/iio/buffer/hw-consumer.c` -* struct :c:type:`iio_hw_consumer` — Hardware consumer structure +* struct iio_hw_consumer — Hardware consumer structure * :c:func:`iio_hw_consumer_alloc` — Allocate IIO hardware consumer * :c:func:`iio_hw_consumer_free` — Free IIO hardware consumer * :c:func:`iio_hw_consumer_enable` — Enable IIO hardware consumer diff --git a/Documentation/driver-api/iio/triggered-buffers.rst b/Documentation/driver-api/iio/triggered-buffers.rst index 0db12660cc90..417555dbbdf4 100644 --- a/Documentation/driver-api/iio/triggered-buffers.rst +++ b/Documentation/driver-api/iio/triggered-buffers.rst @@ -10,7 +10,7 @@ IIO triggered buffer setup * :c:func:`iio_triggered_buffer_setup` — Setup triggered buffer and pollfunc * :c:func:`iio_triggered_buffer_cleanup` — Free resources allocated by :c:func:`iio_triggered_buffer_setup` -* struct :c:type:`iio_buffer_setup_ops` — buffer setup related callbacks +* struct iio_buffer_setup_ops — buffer setup related callbacks A typical triggered buffer setup looks like this:: diff --git a/Documentation/driver-api/iio/triggers.rst b/Documentation/driver-api/iio/triggers.rst index dfd7ba3eabde..288625e40672 100644 --- a/Documentation/driver-api/iio/triggers.rst +++ b/Documentation/driver-api/iio/triggers.rst @@ -2,7 +2,7 @@ Triggers ======== -* struct :c:type:`iio_trigger` — industrial I/O trigger device +* struct iio_trigger — industrial I/O trigger device * :c:func:`devm_iio_trigger_alloc` — Resource-managed iio_trigger_alloc * :c:func:`devm_iio_trigger_register` — Resource-managed iio_trigger_register iio_trigger_unregister @@ -63,7 +63,7 @@ Let's see a simple example of how to setup a trigger to be used by a driver:: IIO trigger ops =============== -* struct :c:type:`iio_trigger_ops` — operations structure for an iio_trigger. +* struct iio_trigger_ops — operations structure for an iio_trigger. Notice that a trigger has a set of operations attached: diff --git a/Documentation/driver-api/media/dtv-frontend.rst b/Documentation/driver-api/media/dtv-frontend.rst index b362109bb131..91f77fe58e83 100644 --- a/Documentation/driver-api/media/dtv-frontend.rst +++ b/Documentation/driver-api/media/dtv-frontend.rst @@ -125,7 +125,7 @@ responsible for tuning the device. It supports multiple algorithms to detect a channel, as defined at enum :c:func:`dvbfe_algo`. The algorithm to be used is obtained via ``.get_frontend_algo``. If the driver -doesn't fill its field at struct :c:type:`dvb_frontend_ops`, it will default to +doesn't fill its field at struct dvb_frontend_ops, it will default to ``DVBFE_ALGO_SW``, meaning that the dvb-core will do a zigzag when tuning, e. g. it will try first to use the specified center frequency ``f``, then, it will do ``f`` + |delta|, ``f`` - |delta|, ``f`` + 2 x |delta|, @@ -140,7 +140,7 @@ define a ``.get_frontend_algo`` function that would return ``DVBFE_ALGO_HW``. a third type (``DVBFE_ALGO_CUSTOM``), in order to allow the driver to define its own hardware-assisted algorithm. Very few hardware need to use it nowadays. Using ``DVBFE_ALGO_CUSTOM`` require to provide other - function callbacks at struct :c:type:`dvb_frontend_ops`. + function callbacks at struct dvb_frontend_ops. Attaching frontend driver to the bridge driver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/driver-api/media/mc-core.rst b/Documentation/driver-api/media/mc-core.rst index 05bba0b61748..57b5bbba944e 100644 --- a/Documentation/driver-api/media/mc-core.rst +++ b/Documentation/driver-api/media/mc-core.rst @@ -36,7 +36,7 @@ pad to a sink pad. Media device ^^^^^^^^^^^^ -A media device is represented by a struct :c:type:`media_device` +A media device is represented by a struct media_device instance, defined in ``include/media/media-device.h``. Allocation of the structure is handled by the media device driver, usually by embedding the :c:type:`media_device` instance in a larger driver-specific @@ -49,7 +49,7 @@ and unregistered by calling :c:func:`media_device_unregister()`. Entities ^^^^^^^^ -Entities are represented by a struct :c:type:`media_entity` +Entities are represented by a struct media_entity instance, defined in ``include/media/media-entity.h``. The structure is usually embedded into a higher-level structure, such as :c:type:`v4l2_subdev` or :c:type:`video_device` @@ -67,10 +67,10 @@ Interfaces ^^^^^^^^^^ Interfaces are represented by a -struct :c:type:`media_interface` instance, defined in +struct media_interface instance, defined in ``include/media/media-entity.h``. Currently, only one type of interface is defined: a device node. Such interfaces are represented by a -struct :c:type:`media_intf_devnode`. +struct media_intf_devnode. Drivers initialize and create device node interfaces by calling :c:func:`media_devnode_create()` @@ -79,7 +79,7 @@ and remove them by calling: Pads ^^^^ -Pads are represented by a struct :c:type:`media_pad` instance, +Pads are represented by a struct media_pad instance, defined in ``include/media/media-entity.h``. Each entity stores its pads in a pads array managed by the entity driver. Drivers usually embed the array in a driver-specific structure. @@ -87,8 +87,8 @@ a driver-specific structure. Pads are identified by their entity and their 0-based index in the pads array. -Both information are stored in the struct :c:type:`media_pad`, -making the struct :c:type:`media_pad` pointer the canonical way +Both information are stored in the struct media_pad, +making the struct media_pad pointer the canonical way to store and pass link references. Pads have flags that describe the pad capabilities and state. @@ -104,7 +104,7 @@ Pads have flags that describe the pad capabilities and state. Links ^^^^^ -Links are represented by a struct :c:type:`media_link` instance, +Links are represented by a struct media_link instance, defined in ``include/media/media-entity.h``. There are two types of links: **1. pad to pad links**: @@ -187,7 +187,7 @@ Use count and power handling Due to the wide differences between drivers regarding power management needs, the media controller does not implement power management. However, -the struct :c:type:`media_entity` includes a ``use_count`` +the struct media_entity includes a ``use_count`` field that media drivers can use to track the number of users of every entity for power management needs. @@ -213,11 +213,11 @@ prevent link states from being modified during streaming by calling The function will mark all entities connected to the given entity through enabled links, either directly or indirectly, as streaming. -The struct :c:type:`media_pipeline` instance pointed to by +The struct media_pipeline instance pointed to by the pipe argument will be stored in every entity in the pipeline. -Drivers should embed the struct :c:type:`media_pipeline` +Drivers should embed the struct media_pipeline in higher-level pipeline structures and can then access the -pipeline through the struct :c:type:`media_entity` +pipeline through the struct media_entity pipe field. Calls to :c:func:`media_pipeline_start()` can be nested. diff --git a/Documentation/driver-api/media/v4l2-controls.rst b/Documentation/driver-api/media/v4l2-controls.rst index 5129019afb49..77f42ea3bac7 100644 --- a/Documentation/driver-api/media/v4l2-controls.rst +++ b/Documentation/driver-api/media/v4l2-controls.rst @@ -27,7 +27,7 @@ V4L2 specification with respect to controls in a central place. And to make life as easy as possible for the driver developer. Note that the control framework relies on the presence of a struct -:c:type:`v4l2_device` for V4L2 drivers and struct :c:type:`v4l2_subdev` for +:c:type:`v4l2_device` for V4L2 drivers and struct v4l2_subdev for sub-device drivers. diff --git a/Documentation/driver-api/media/v4l2-dev.rst b/Documentation/driver-api/media/v4l2-dev.rst index 63c064837c00..666330af31ed 100644 --- a/Documentation/driver-api/media/v4l2-dev.rst +++ b/Documentation/driver-api/media/v4l2-dev.rst @@ -67,7 +67,7 @@ You should also set these fields of :c:type:`video_device`: file operation is called this lock will be taken by the core and released afterwards. See the next section for more details. -- :c:type:`video_device`->queue: a pointer to the struct :c:type:`vb2_queue` +- :c:type:`video_device`->queue: a pointer to the struct vb2_queue associated with this device node. If queue is not ``NULL``, and queue->lock is not ``NULL``, then queue->lock is used for the queuing ioctls (``VIDIOC_REQBUFS``, ``CREATE_BUFS``, @@ -81,7 +81,7 @@ You should also set these fields of :c:type:`video_device`: - :c:type:`video_device`->prio: keeps track of the priorities. Used to implement ``VIDIOC_G_PRIORITY`` and ``VIDIOC_S_PRIORITY``. - If left to ``NULL``, then it will use the struct :c:type:`v4l2_prio_state` + If left to ``NULL``, then it will use the struct v4l2_prio_state in :c:type:`v4l2_device`. If you want to have a separate priority state per (group of) device node(s), then you can point it to your own struct :c:type:`v4l2_prio_state`. @@ -95,7 +95,7 @@ You should also set these fields of :c:type:`video_device`: but it is used by both a raw video PCI device (cx8800) and a MPEG PCI device (cx8802). Since the :c:type:`v4l2_device` cannot be associated with two PCI devices at the same time it is setup without a parent device. But when the - struct :c:type:`video_device` is initialized you **do** know which parent + struct video_device is initialized you **do** know which parent PCI device to use and so you set ``dev_device`` to the correct PCI device. If you use :c:type:`v4l2_ioctl_ops`, then you should set @@ -138,7 +138,7 @@ ioctls and locking ------------------ The V4L core provides optional locking services. The main service is the -lock field in struct :c:type:`video_device`, which is a pointer to a mutex. +lock field in struct video_device, which is a pointer to a mutex. If you set this pointer, then that will be used by unlocked_ioctl to serialize all ioctls. diff --git a/Documentation/driver-api/media/v4l2-device.rst b/Documentation/driver-api/media/v4l2-device.rst index 5e25bf182c18..7bd9c45f551b 100644 --- a/Documentation/driver-api/media/v4l2-device.rst +++ b/Documentation/driver-api/media/v4l2-device.rst @@ -3,7 +3,7 @@ V4L2 device instance -------------------- -Each device instance is represented by a struct :c:type:`v4l2_device`. +Each device instance is represented by a struct v4l2_device. Very simple devices can just allocate this struct, but most of the time you would embed this struct inside a larger struct. @@ -18,9 +18,9 @@ dev->driver_data field is ``NULL``, it will be linked to Drivers that want integration with the media device framework need to set dev->driver_data manually to point to the driver-specific device structure -that embed the struct :c:type:`v4l2_device` instance. This is achieved by a +that embed the struct v4l2_device instance. This is achieved by a ``dev_set_drvdata()`` call before registering the V4L2 device instance. -They must also set the struct :c:type:`v4l2_device` mdev field to point to a +They must also set the struct v4l2_device mdev field to point to a properly initialized and registered :c:type:`media_device` instance. If :c:type:`v4l2_dev <v4l2_device>`\ ->name is empty then it will be set to a diff --git a/Documentation/driver-api/media/v4l2-event.rst b/Documentation/driver-api/media/v4l2-event.rst index a4b7ae2b94d8..5b8254eba7da 100644 --- a/Documentation/driver-api/media/v4l2-event.rst +++ b/Documentation/driver-api/media/v4l2-event.rst @@ -44,18 +44,18 @@ such objects. So to summarize: -- struct :c:type:`v4l2_fh` has two lists: one of the ``subscribed`` events, +- struct v4l2_fh has two lists: one of the ``subscribed`` events, and one of the ``available`` events. -- struct :c:type:`v4l2_subscribed_event` has a ringbuffer of raised +- struct v4l2_subscribed_event has a ringbuffer of raised (pending) events of that particular type. -- If struct :c:type:`v4l2_subscribed_event` is associated with a specific +- If struct v4l2_subscribed_event is associated with a specific object, then that object will have an internal list of - struct :c:type:`v4l2_subscribed_event` so it knows who subscribed an + struct v4l2_subscribed_event so it knows who subscribed an event to that object. -Furthermore, the internal struct :c:type:`v4l2_subscribed_event` has +Furthermore, the internal struct v4l2_subscribed_event has ``merge()`` and ``replace()`` callbacks which drivers can set. These callbacks are called when a new event is raised and there is no more room. diff --git a/Documentation/driver-api/media/v4l2-fh.rst b/Documentation/driver-api/media/v4l2-fh.rst index 4c62b19af744..3eeaa8da0c9e 100644 --- a/Documentation/driver-api/media/v4l2-fh.rst +++ b/Documentation/driver-api/media/v4l2-fh.rst @@ -3,11 +3,11 @@ V4L2 File handlers ------------------ -struct :c:type:`v4l2_fh` provides a way to easily keep file handle specific +struct v4l2_fh provides a way to easily keep file handle specific data that is used by the V4L2 framework. .. attention:: - New drivers must use struct :c:type:`v4l2_fh` + New drivers must use struct v4l2_fh since it is also used to implement priority handling (:ref:`VIDIOC_G_PRIORITY`). @@ -16,11 +16,11 @@ whether a driver uses :c:type:`v4l2_fh` as its ``file->private_data`` pointer by testing the ``V4L2_FL_USES_V4L2_FH`` bit in :c:type:`video_device`->flags. This bit is set whenever :c:func:`v4l2_fh_init` is called. -struct :c:type:`v4l2_fh` is allocated as a part of the driver's own file handle +struct v4l2_fh is allocated as a part of the driver's own file handle structure and ``file->private_data`` is set to it in the driver's ``open()`` function by the driver. -In many cases the struct :c:type:`v4l2_fh` will be embedded in a larger +In many cases the struct v4l2_fh will be embedded in a larger structure. In that case you should call: #) :c:func:`v4l2_fh_init` and :c:func:`v4l2_fh_add` in ``open()`` @@ -102,18 +102,18 @@ Below is a short description of the :c:type:`v4l2_fh` functions used: memory can be freed. -If struct :c:type:`v4l2_fh` is not embedded, then you can use these helper functions: +If struct v4l2_fh is not embedded, then you can use these helper functions: :c:func:`v4l2_fh_open <v4l2_fh_open>` (struct file \*filp) -- This allocates a struct :c:type:`v4l2_fh`, initializes it and adds it to - the struct :c:type:`video_device` associated with the file struct. +- This allocates a struct v4l2_fh, initializes it and adds it to + the struct video_device associated with the file struct. :c:func:`v4l2_fh_release <v4l2_fh_release>` (struct file \*filp) -- This deletes it from the struct :c:type:`video_device` associated with the +- This deletes it from the struct video_device associated with the file struct, uninitialised the :c:type:`v4l2_fh` and frees it. These two functions can be plugged into the v4l2_file_operation's ``open()`` diff --git a/Documentation/driver-api/media/v4l2-subdev.rst b/Documentation/driver-api/media/v4l2-subdev.rst index 6248ea99e979..bb5b1a7cdfd9 100644 --- a/Documentation/driver-api/media/v4l2-subdev.rst +++ b/Documentation/driver-api/media/v4l2-subdev.rst @@ -110,7 +110,7 @@ pads: err = media_entity_pads_init(&sd->entity, npads, pads); The pads array must have been previously initialized. There is no need to -manually set the struct :c:type:`media_entity` function and name fields, but the +manually set the struct media_entity function and name fields, but the revision field must be initialized if needed. A reference to the entity will be automatically acquired/released when the diff --git a/Documentation/driver-api/regulator.rst b/Documentation/driver-api/regulator.rst index 520da0a5251d..b43c78eb24d8 100644 --- a/Documentation/driver-api/regulator.rst +++ b/Documentation/driver-api/regulator.rst @@ -116,7 +116,7 @@ core, providing operations structures to the core. A notifier interface allows error conditions to be reported to the core. Registration should be triggered by explicit setup done by the platform, -supplying a struct :c:type:`regulator_init_data` for the regulator +supplying a struct regulator_init_data for the regulator containing constraint and supply information. Machine interface @@ -144,7 +144,7 @@ a given system, for example supporting higher supply voltages than the consumers are rated for. This is done at driver registration time` by providing a -struct :c:type:`regulation_constraints`. +struct regulation_constraints. The constraints may also specify an initial configuration for the regulator in the constraints, which is particularly useful for use with diff --git a/Documentation/driver-api/usb/URB.rst b/Documentation/driver-api/usb/URB.rst index 1e4abc896a0d..a182c0f5e38a 100644 --- a/Documentation/driver-api/usb/URB.rst +++ b/Documentation/driver-api/usb/URB.rst @@ -47,7 +47,7 @@ called USB Request Block, or URB for short. The URB structure ================= -Some of the fields in struct :c:type:`urb` are:: +Some of the fields in struct urb are:: struct urb { diff --git a/Documentation/driver-api/usb/gadget.rst b/Documentation/driver-api/usb/gadget.rst index 3e8a3809c0b8..09396edd6131 100644 --- a/Documentation/driver-api/usb/gadget.rst +++ b/Documentation/driver-api/usb/gadget.rst @@ -176,9 +176,9 @@ Kernel Mode Gadget API Gadget drivers declare themselves through a struct :c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration -for a struct :c:type:`usb_gadget`. The response to a set_configuration usually -involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by -the gadget, and submitting one or more struct :c:type:`usb_request` buffers to +for a struct usb_gadget. The response to a set_configuration usually +involves enabling one or more of the struct usb_ep objects exposed by +the gadget, and submitting one or more struct usb_request buffers to transfer data. Understand those four data types, and their operations, and you will understand how this API works. @@ -339,8 +339,8 @@ multi-configuration devices (also more than one function, but not necessarily sharing a given configuration). There is however an optional framework which makes it easier to reuse and combine functions. -Devices using this framework provide a struct :c:type:`usb_composite_driver`, -which in turn provides one or more struct :c:type:`usb_configuration` +Devices using this framework provide a struct usb_composite_driver, +which in turn provides one or more struct usb_configuration instances. Each such configuration includes at least one struct :c:type:`usb_function`, which packages a user visible role such as "network link" or "mass storage device". Management functions may also exist, diff --git a/Documentation/driver-api/usb/hotplug.rst b/Documentation/driver-api/usb/hotplug.rst index 79663e653ca1..c1e13107c50e 100644 --- a/Documentation/driver-api/usb/hotplug.rst +++ b/Documentation/driver-api/usb/hotplug.rst @@ -122,7 +122,7 @@ and their quirks, might have a MODULE_DEVICE_TABLE like this:: Most USB device drivers should pass these tables to the USB subsystem as well as to the module management subsystem. Not all, though: some driver frameworks connect using interfaces layered over USB, and so they won't -need such a struct :c:type:`usb_driver`. +need such a struct usb_driver. Drivers that connect directly to the USB subsystem should be declared something like this:: diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 423c5a0daf45..4f858b38a412 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -437,7 +437,7 @@ FS_IOC_SET_ENCRYPTION_POLICY The FS_IOC_SET_ENCRYPTION_POLICY ioctl sets an encryption policy on an empty directory or verifies that a directory or regular file already has the specified encryption policy. It takes in a pointer to a -:c:type:`struct fscrypt_policy_v1` or a :c:type:`struct +struct fscrypt_policy_v1 or a :c:type:`struct fscrypt_policy_v2`, defined as follows:: #define FSCRYPT_POLICY_V1 0 @@ -508,7 +508,7 @@ This structure must be initialized as follows: replaced with ``master_key_identifier``, which is longer and cannot be arbitrarily chosen. Instead, the key must first be added using `FS_IOC_ADD_ENCRYPTION_KEY`_. Then, the ``key_spec.u.identifier`` - the kernel returned in the :c:type:`struct fscrypt_add_key_arg` must + the kernel returned in the struct fscrypt_add_key_arg must be used as the ``master_key_identifier`` in the :c:type:`struct fscrypt_policy_v2`. @@ -590,7 +590,7 @@ FS_IOC_GET_ENCRYPTION_POLICY_EX The FS_IOC_GET_ENCRYPTION_POLICY_EX ioctl retrieves the encryption policy, if any, for a directory or regular file. No additional permissions are required beyond the ability to open the file. It -takes in a pointer to a :c:type:`struct fscrypt_get_policy_ex_arg`, +takes in a pointer to a struct fscrypt_get_policy_ex_arg, defined as follows:: struct fscrypt_get_policy_ex_arg { @@ -680,7 +680,7 @@ the filesystem, making all files on the filesystem which were encrypted using that key appear "unlocked", i.e. in plaintext form. It can be executed on any file or directory on the target filesystem, but using the filesystem's root directory is recommended. It takes in -a pointer to a :c:type:`struct fscrypt_add_key_arg`, defined as +a pointer to a struct fscrypt_add_key_arg, defined as follows:: struct fscrypt_add_key_arg { @@ -710,7 +710,7 @@ follows:: __u8 raw[]; }; -:c:type:`struct fscrypt_add_key_arg` must be zeroed, then initialized +struct fscrypt_add_key_arg must be zeroed, then initialized as follows: - If the key is being added for use by v1 encryption policies, then @@ -860,7 +860,7 @@ The FS_IOC_REMOVE_ENCRYPTION_KEY ioctl removes a claim to a master encryption key from the filesystem, and possibly removes the key itself. It can be executed on any file or directory on the target filesystem, but using the filesystem's root directory is recommended. -It takes in a pointer to a :c:type:`struct fscrypt_remove_key_arg`, +It takes in a pointer to a struct fscrypt_remove_key_arg, defined as follows:: struct fscrypt_remove_key_arg { @@ -1149,7 +1149,7 @@ Encryption context ------------------ An encryption policy is represented on-disk by a :c:type:`struct -fscrypt_context_v1` or a :c:type:`struct fscrypt_context_v2`. It is +fscrypt_context_v1` or a struct fscrypt_context_v2. It is up to individual filesystems to decide where to store it, but normally it would be stored in a hidden extended attribute. It should *not* be exposed by the xattr-related system calls such as getxattr() and diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index 6c8944f6f0f7..895e9711ed88 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -84,7 +84,7 @@ FS_IOC_ENABLE_VERITY -------------------- The FS_IOC_ENABLE_VERITY ioctl enables fs-verity on a file. It takes -in a pointer to a :c:type:`struct fsverity_enable_arg`, defined as +in a pointer to a struct fsverity_enable_arg, defined as follows:: struct fsverity_enable_arg { diff --git a/Documentation/sound/designs/tracepoints.rst b/Documentation/sound/designs/tracepoints.rst index 78bc5572f829..b0a7e3010187 100644 --- a/Documentation/sound/designs/tracepoints.rst +++ b/Documentation/sound/designs/tracepoints.rst @@ -34,20 +34,20 @@ substream. In this procedure, PCM hardware parameters are decided by interaction between applications and ALSA PCM core. Once decided, runtime of the PCM substream keeps the parameters. -The parameters are described in :c:type:`struct snd_pcm_hw_params`. This +The parameters are described in struct snd_pcm_hw_params. This structure includes several types of parameters. Applications set preferable value to these parameters, then execute ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE or SNDRV_PCM_IOCTL_HW_PARAMS. The former is used just for refining available set of parameters. The latter is used for an actual decision of the parameters. -The :c:type:`struct snd_pcm_hw_params` structure has below members: +The struct snd_pcm_hw_params structure has below members: ``flags`` Configurable. ALSA PCM core and some drivers handle this flag to select convenient parameters or change their behaviour. ``masks`` Configurable. This type of parameter is described in - :c:type:`struct snd_mask` and represent mask values. As of PCM protocol + struct snd_mask and represent mask values. As of PCM protocol v2.0.13, three types are defined. - SNDRV_PCM_HW_PARAM_ACCESS @@ -55,7 +55,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: - SNDRV_PCM_HW_PARAM_SUBFORMAT ``intervals`` Configurable. This type of parameter is described in - :c:type:`struct snd_interval` and represent values with a range. As of + struct snd_interval and represent values with a range. As of PCM protocol v2.0.13, twelve types are defined. - SNDRV_PCM_HW_PARAM_SAMPLE_BITS @@ -78,7 +78,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: are going to be changed. ``cmask`` Read-only. After returning from ioctl(2), buffer in user space for - :c:type:`struct snd_pcm_hw_params` includes result of each operation. + struct snd_pcm_hw_params includes result of each operation. This mask represents which mask/interval parameter is actually changed. ``info`` Read-only. This represents hardware/driver capabilities as bit flags @@ -110,10 +110,10 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: value to this parameter but some drivers intentionally set zero with a care of hardware design or data transmission protocol. -ALSA PCM core handles buffer of :c:type:`struct snd_pcm_hw_params` when +ALSA PCM core handles buffer of struct snd_pcm_hw_params when applications execute ioctl(2) with SNDRV_PCM_HW_REFINE or SNDRV_PCM_HW_PARAMS. Parameters in the buffer are changed according to -:c:type:`struct snd_pcm_hardware` and rules of constraints in the runtime. The +struct snd_pcm_hardware and rules of constraints in the runtime. The structure describes capabilities of handled hardware. The rules describes dependencies on which a parameter is decided according to several parameters. A rule has a callback function, and drivers can register arbitrary functions @@ -121,17 +121,17 @@ to compute the target parameter. ALSA PCM core registers some rules to the runtime as a default. Each driver can join in the interaction as long as it prepared for two stuffs -in a callback of :c:type:`struct snd_pcm_ops.open`. +in a callback of struct snd_pcm_ops.open. 1. In the callback, drivers are expected to change a member of - :c:type:`struct snd_pcm_hardware` type in the runtime, according to + struct snd_pcm_hardware type in the runtime, according to capacities of corresponding hardware. 2. In the same callback, drivers are also expected to register additional rules of constraints into the runtime when several parameters have dependencies due to hardware design. The driver can refers to result of the interaction in a callback of -:c:type:`struct snd_pcm_ops.hw_params`, however it should not change the +struct snd_pcm_ops.hw_params, however it should not change the content. Tracepoints in this category are designed to trace changes of the @@ -163,7 +163,7 @@ fields are different according to type of the parameter. For parameters of mask type, the fields represent hexadecimal dump of content of the parameter. For parameters of interval type, the fields represent values of each member of ``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in -:c:type:`struct snd_interval` in this order. +struct snd_interval in this order. Tracepoints in drivers ====================== diff --git a/Documentation/sphinx/parse-headers.pl b/Documentation/sphinx/parse-headers.pl index 00a69aceff44..1910079f984f 100755 --- a/Documentation/sphinx/parse-headers.pl +++ b/Documentation/sphinx/parse-headers.pl @@ -110,7 +110,7 @@ while (<IN>) { ) { my $s = $1; - $structs{$s} = "struct :c:type:`$s`\\ "; + $structs{$s} = "struct $s\\ "; next; } } diff --git a/Documentation/vm/ksm.rst b/Documentation/vm/ksm.rst index d1b7270ad55c..9e37add068e6 100644 --- a/Documentation/vm/ksm.rst +++ b/Documentation/vm/ksm.rst @@ -26,7 +26,7 @@ tree. If a KSM page is shared between less than ``max_page_sharing`` VMAs, the node of the stable tree that represents such KSM page points to a -list of :c:type:`struct rmap_item` and the ``page->mapping`` of the +list of struct rmap_item and the ``page->mapping`` of the KSM page points to the stable tree node. When the sharing passes this threshold, KSM adds a second dimension to diff --git a/Documentation/vm/memory-model.rst b/Documentation/vm/memory-model.rst index 769449734573..9daadf9faba1 100644 --- a/Documentation/vm/memory-model.rst +++ b/Documentation/vm/memory-model.rst @@ -24,7 +24,7 @@ whether it is possible to manually override that default. although it is still in use by several architectures. All the memory models track the status of physical page frames using -:c:type:`struct page` arranged in one or more arrays. +struct page arranged in one or more arrays. Regardless of the selected memory model, there exists one-to-one mapping between the physical page frame number (PFN) and the @@ -111,7 +111,7 @@ maps for non-volatile memory devices and deferred initialization of the memory map for larger systems. The SPARSEMEM model presents the physical memory as a collection of -sections. A section is represented with :c:type:`struct mem_section` +sections. A section is represented with struct mem_section that contains `section_mem_map` that is, logically, a pointer to an array of struct pages. However, it is stored with some other magic that aids the sections management. The section size and maximal number @@ -172,7 +172,7 @@ management. The virtually mapped memory map allows storing `struct page` objects for persistent memory devices in pre-allocated storage on those -devices. This storage is represented with :c:type:`struct vmem_altmap` +devices. This storage is represented with struct vmem_altmap that is eventually passed to vmemmap_populate() through a long chain of function calls. The vmemmap_populate() implementation may use the `vmem_altmap` along with :c:func:`vmemmap_alloc_block_buf` helper to diff --git a/mm/ksm.c b/mm/ksm.c index 9afccc36dbd2..0960750bb316 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -81,7 +81,7 @@ * different KSM page copy of that content * * Internally, the regular nodes, "dups" and "chains" are represented - * using the same :c:type:`struct stable_node` structure. + * using the same struct stable_node structure. * * In addition to the stable tree, KSM uses a second data structure called the * unstable tree: this tree holds pointers to pages which have been found to diff --git a/mm/memblock.c b/mm/memblock.c index 326c6b3fec1d..b68ee86788af 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -48,12 +48,12 @@ * boot regardless of the possible restrictions and memory hot(un)plug; * the ``physmem`` type is only available on some architectures. * - * Each region is represented by :c:type:`struct memblock_region` that + * Each region is represented by struct memblock_region that * defines the region extents, its attributes and NUMA node id on NUMA * systems. Every memory type is described by the struct memblock_type * which contains an array of memory regions along with * the allocator metadata. The "memory" and "reserved" types are nicely - * wrapped with :c:type:`struct memblock`. This structure is statically + * wrapped with struct memblock. This structure is statically * initialized at build time. The region arrays are initially sized to * %INIT_MEMBLOCK_REGIONS for "memory" and %INIT_MEMBLOCK_RESERVED_REGIONS * for "reserved". The region array for "physmem" is initially sized to -- 2.26.2

4 3

alsa-info: provide DMI system sku
by GitHub pull_request - opened 30 Sep '20

30 Sep '20

alsa-project/alsa-utils pull request #59 was opened from plbossart: The system sku is used in SOF machine drivers to set specific quirks, expose it in alsa-info to help support users. Example on a SoundWire enabled device: cat /sys/class/dmi/id/product_sku 0A32 dmidecode -s system-sku-number 0A32 Add a variable and expose the results of both methods. Note that the dmidecode support is very recent and might not yet be available in all distros: http://git.savannah.nongnu.org/cgit/dmidecode.git/commit/?id=d70d5e686148ea… Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Request URL : https://github.com/alsa-project/alsa-utils/pull/59 Patch URL : https://github.com/alsa-project/alsa-utils/pull/59.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[PATCH] ASoC: atmel-pcm: remove unnecessary include
by Alexandre Belloni 30 Sep '20

30 Sep '20

Since commit 95e0e07e710e ("ASoC: atmel-pcm: use generic dmaengine framework"), the driver is using dmaengine and is not using any definition from include/linux/platform_data/dma-atmel.h, stop including it. Signed-off-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> --- sound/soc/atmel/atmel-pcm-dma.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/atmel/atmel-pcm-dma.c b/sound/soc/atmel/atmel-pcm-dma.c index e597e35459ce..96a8c7dba98f 100644 --- a/sound/soc/atmel/atmel-pcm-dma.c +++ b/sound/soc/atmel/atmel-pcm-dma.c @@ -18,7 +18,6 @@ #include <linux/dma-mapping.h> #include <linux/dmaengine.h> #include <linux/atmel-ssc.h> -#include <linux/platform_data/dma-atmel.h> #include <sound/core.h> #include <sound/pcm.h> -- 2.26.2

2 1

[PATCH v2 0/2] ALSA: HDA: Early Forbid of runtime PM
by Kai Vehmanen 30 Sep '20

30 Sep '20

Fix a race with runtime PM enabled during codec initialization. For snd-hda-intel, no changes are needed in controller code, but to not break ASoC controller drivers, this V2 series adds an additional change in ASoC hdac_hda to allow runtime pm again at end of probe. Harsha Priya (1): ALSA: HDA: Early Forbid of runtime PM Kai Vehmanen (1): ASoC: hdac_hda: allow runtime pm at end of probe sound/pci/hda/hda_codec.c | 3 +++ sound/soc/codecs/hdac_hda.c | 3 +++ 2 files changed, 6 insertions(+) -- 2.27.0

3 6

[PATCH v4 37/52] docs: sound: writing-an-alsa-driver.rst: get rid of :c:type
by Mauro Carvalho Chehab 30 Sep '20

30 Sep '20

the :c:type shouldn't be used with structs with Sphinx 3, as the C domain there uses .. c:struct for structs. As we have the automarkup extension, let's just get rid of all :c:type as a hole, as those will be automagically marked as such. This solves a bunch of warnings with Sphinx 3, like those: .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:490: WARNING: Unparseable C cross-reference: 'calling snd_card_free' Invalid C declaration: Expected end of definition. [error at 8] calling snd_card_free --------^ .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3328: WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*' Invalid C declaration: Expected end of definition. [error at 20] snd_rawmidi_transmit* --------------------^ .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3928: WARNING: Unparseable C cross-reference: 'copy_from/to_user' Invalid C declaration: Expected end of definition. [error at 9] copy_from/to_user ---------^ Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- .../kernel-api/writing-an-alsa-driver.rst | 105 ++++++++---------- 1 file changed, 47 insertions(+), 58 deletions(-) diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index aa9d5ab183d2..85d6e9c643ef 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -194,7 +194,7 @@ The minimum flow for PCI soundcards is as follows: - create ``remove`` callback. -- create a :c:type:`struct pci_driver <pci_driver>` structure +- create a struct pci_driver structure containing the three pointers above. - create an ``init`` function just calling the @@ -487,7 +487,7 @@ The destructor, remove callback, simply releases the card instance. Then the ALSA middle layer will release all the attached components automatically. -It would be typically just :c:func:`calling snd_card_free()`: +It would be typically just calling :c:func:`snd_card_free()`: :: @@ -560,16 +560,15 @@ return the card instance. The extra_size argument is used to allocate card->private_data for the chip-specific data. Note that these data are allocated by :c:func:`snd_card_new()`. -The first argument, the pointer of struct :c:type:`struct device -<device>`, specifies the parent device. For PCI devices, typically -``&pci->`` is passed there. +The first argument, the pointer of struct device, specifies the parent +device. For PCI devices, typically ``&pci->`` is passed there. Components ---------- After the card is created, you can attach the components (devices) to the card instance. In an ALSA driver, a component is represented as a -:c:type:`struct snd_device <snd_device>` object. A component +struct snd_device object. A component can be a PCM instance, a control interface, a raw MIDI interface, etc. Each such instance has one component entry. @@ -628,7 +627,7 @@ argument of :c:func:`snd_card_new()`, i.e. err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, sizeof(struct mychip), &card); -:c:type:`struct mychip <mychip>` is the type of the chip record. +struct mychip is the type of the chip record. In return, the allocated record can be accessed as @@ -890,7 +889,7 @@ functions. These resources must be released in the destructor function (see below). Now assume that the PCI device has an I/O port with 8 bytes and an -interrupt. Then :c:type:`struct mychip <mychip>` will have the +interrupt. Then struct mychip will have the following fields: :: @@ -1094,7 +1093,7 @@ PCI Entries ----------- So far, so good. Let's finish the missing PCI stuff. At first, we need a -:c:type:`struct pci_device_id <pci_device_id>` table for +struct pci_device_id table for this chipset. It's a table of PCI vendor/device ID number, and some masks. @@ -1110,19 +1109,17 @@ For example, }; MODULE_DEVICE_TABLE(pci, snd_mychip_ids); -The first and second fields of the :c:type:`struct pci_device_id -<pci_device_id>` structure are the vendor and device IDs. If you -have no reason to filter the matching devices, you can leave the -remaining fields as above. The last field of the :c:type:`struct -pci_device_id <pci_device_id>` struct contains private data -for this entry. You can specify any value here, for example, to define -specific operations for supported device IDs. Such an example is found -in the intel8x0 driver. +The first and second fields of the struct pci_device_id are the vendor +and device IDs. If you have no reason to filter the matching devices, you can +leave the remaining fields as above. The last field of the +struct pci_device_id contains private data for this entry. You can specify +any value here, for example, to define specific operations for supported +device IDs. Such an example is found in the intel8x0 driver. The last entry of this list is the terminator. You must specify this all-zero entry. -Then, prepare the :c:type:`struct pci_driver <pci_driver>` +Then, prepare the struct pci_driver record: :: @@ -1439,8 +1436,8 @@ corresponding argument. If a chip supports multiple playbacks or captures, you can specify more numbers, but they must be handled properly in open/close, etc. callbacks. When you need to know which substream you are referring to, -then it can be obtained from :c:type:`struct snd_pcm_substream -<snd_pcm_substream>` data passed to each callback as follows: +then it can be obtained from struct snd_pcm_substream data passed to each +callback as follows: :: @@ -1639,10 +1636,9 @@ In the sections below, important records are explained. Hardware Description ~~~~~~~~~~~~~~~~~~~~ -The hardware descriptor (:c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>`) contains the definitions of the fundamental -hardware configuration. Above all, you'll need to define this in the -`PCM open callback`_. Note that the runtime instance holds the copy of +The hardware descriptor (struct snd_pcm_hardware) contains the definitions of +the fundamental hardware configuration. Above all, you'll need to define this +in the `PCM open callback`_. Note that the runtime instance holds the copy of the descriptor, not the pointer to the existing descriptor. That is, in the open callback, you can modify the copied descriptor (``runtime->hw``) as you need. For example, if the maximum number of @@ -1800,14 +1796,13 @@ Running Status ~~~~~~~~~~~~~~ The running status can be referred via ``runtime->status``. This is -the pointer to the :c:type:`struct snd_pcm_mmap_status -<snd_pcm_mmap_status>` record. For example, you can get the current +the pointer to the struct snd_pcm_mmap_status record. +For example, you can get the current DMA hardware pointer via ``runtime->status->hw_ptr``. The DMA application pointer can be referred via ``runtime->control``, -which points to the :c:type:`struct snd_pcm_mmap_control -<snd_pcm_mmap_control>` record. However, accessing directly to -this value is not recommended. +which points to the struct snd_pcm_mmap_control record. +However, accessing directly to this value is not recommended. Private Data ~~~~~~~~~~~~ @@ -1843,8 +1838,8 @@ error number such as ``-EINVAL``. To choose an appropriate error number, it is advised to check what value other parts of the kernel return when the same kind of request fails. -The callback function takes at least the argument with :c:type:`struct -snd_pcm_substream <snd_pcm_substream>` pointer. To retrieve the chip +The callback function takes at least the argument with +struct snd_pcm_substream pointer. To retrieve the chip record from the given substream instance, you can use the following macro. @@ -2313,10 +2308,10 @@ non-atomic contexts. For example, the function :c:func:`snd_pcm_period_elapsed()` is called typically from the interrupt handler. But, if you set up the driver to use a threaded interrupt handler, this call can be in non-atomic context, too. In such -a case, you can set ``nonatomic`` filed of :c:type:`struct snd_pcm -<snd_pcm>` object after creating it. When this flag is set, mutex -and rwsem are used internally in the PCM core instead of spin and -rwlocks, so that you can call all PCM functions safely in a non-atomic +a case, you can set ``nonatomic`` filed of struct snd_pcm object +after creating it. When this flag is set, mutex and rwsem are used internally +in the PCM core instead of spin and rwlocks, so that you can call all PCM +functions safely in a non-atomic context. Constraints @@ -2357,8 +2352,7 @@ There are many different constraints. Look at ``sound/pcm.h`` for a complete list. You can even define your own constraint rules. For example, let's suppose my_chip can manage a substream of 1 channel if and only if the format is ``S16_LE``, otherwise it supports any format -specified in the :c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>` structure (or in any other +specified in struct snd_pcm_hardware> (or in any other constraint_list). You can build a rule like this: :: @@ -2467,7 +2461,7 @@ Definition of Controls To create a new control, you need to define the following three callbacks: ``info``, ``get`` and ``put``. Then, define a -:c:type:`struct snd_kcontrol_new <snd_kcontrol_new>` record, such as: +struct snd_kcontrol_new record, such as: :: @@ -2602,8 +2596,8 @@ info callback ~~~~~~~~~~~~~ The ``info`` callback is used to get detailed information on this -control. This must store the values of the given :c:type:`struct -snd_ctl_elem_info <snd_ctl_elem_info>` object. For example, +control. This must store the values of the given +struct snd_ctl_elem_info object. For example, for a boolean control with a single element: :: @@ -2774,13 +2768,11 @@ In the simplest way, you can do like this: if (err < 0) return err; -where ``my_control`` is the :c:type:`struct snd_kcontrol_new -<snd_kcontrol_new>` object defined above, and chip is the object -pointer to be passed to kcontrol->private_data which can be referred -to in callbacks. +where ``my_control`` is the struct snd_kcontrol_new object defined above, +and chip is the object pointer to be passed to kcontrol->private_data which +can be referred to in callbacks. -:c:func:`snd_ctl_new1()` allocates a new :c:type:`struct -snd_kcontrol <snd_kcontrol>` instance, and +:c:func:`snd_ctl_new1()` allocates a new struct snd_kcontrol instance, and :c:func:`snd_ctl_add()` assigns the given control component to the card. @@ -2797,10 +2789,9 @@ can call :c:func:`snd_ctl_notify()`. For example, This function takes the card pointer, the event-mask, and the control id pointer for the notification. The event-mask specifies the types of notification, for example, in the above example, the change of control -values is notified. The id pointer is the pointer of :c:type:`struct -snd_ctl_elem_id <snd_ctl_elem_id>` to be notified. You can -find some examples in ``es1938.c`` or ``es1968.c`` for hardware volume -interrupts. +values is notified. The id pointer is the pointer of struct snd_ctl_elem_id +to be notified. You can find some examples in ``es1938.c`` or ``es1968.c`` +for hardware volume interrupts. Metadata -------- @@ -2915,9 +2906,8 @@ with an ``ac97_bus_ops_t`` record with callback functions. The bus record is shared among all belonging ac97 instances. -And then call :c:func:`snd_ac97_mixer()` with an :c:type:`struct -snd_ac97_template <snd_ac97_template>` record together with -the bus pointer created above. +And then call :c:func:`snd_ac97_mixer()` with an struct snd_ac97_template +record together with the bus pointer created above. :: @@ -3118,11 +3108,10 @@ devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see Usually, the port address corresponds to the command port and port + 1 corresponds to the data port. If not, you may change the ``cport`` -field of :c:type:`struct snd_mpu401 <snd_mpu401>` manually afterward. -However, :c:type:`struct snd_mpu401 <snd_mpu401>` pointer is +field of struct snd_mpu401 manually afterward. +However, struct snd_mpu401 pointer is not returned explicitly by :c:func:`snd_mpu401_uart_new()`. You -need to cast ``rmidi->private_data`` to :c:type:`struct snd_mpu401 -<snd_mpu401>` explicitly, +need to cast ``rmidi->private_data`` to struct snd_mpu401 explicitly, :: @@ -3772,7 +3761,7 @@ For creating the SG-buffer handler, call :c:func:`snd_pcm_set_managed_buffer_all()` with ``SNDRV_DMA_TYPE_DEV_SG`` in the PCM constructor like other PCI pre-allocator. You need to pass ``&pci->dev``, where pci is -the :c:type:`struct pci_dev <pci_dev>` pointer of the chip as +the struct pci_dev pointer of the chip as well. :: -- 2.26.2

2 1

[PATCH v4 39/52] docs: writing-an-alsa-driver.rst: fix some bad c:func: markups
by Mauro Carvalho Chehab 30 Sep '20

30 Sep '20

Some such markups are invalid, as reported by Sphinx: ./Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3317: WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*' Invalid C declaration: Expected end of definition. [error at 20] snd_rawmidi_transmit* --------------------^ ./Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3917: WARNING: Unparseable C cross-reference: 'copy_from/to_user' Invalid C declaration: Expected end of definition. [error at 9] copy_from/to_user ---------^ The first case seems to be better replaced by a literal. For the second one, let's generate cross-references, by spliting it in two. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 85d6e9c643ef..73bbd59afc33 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -3315,8 +3315,7 @@ data and removes them from the buffer at once: } If you know beforehand how many bytes you can accept, you can use a -buffer size greater than one with the -:c:func:`snd_rawmidi_transmit\*()` functions. +buffer size greater than one with the ``snd_rawmidi_transmit*()`` functions. The ``trigger`` callback must not sleep. If the hardware FIFO is full before the substream buffer has been emptied, you have to continue @@ -3916,7 +3915,7 @@ the maximum size of the proc file access. The read/write callbacks of raw mode are more direct than the text mode. You need to use a low-level I/O functions such as -:c:func:`copy_from/to_user()` to transfer the data. +:c:func:`copy_from_user()` and :c:func:`copy_to_user()` to transfer the data. :: -- 2.26.2

2 1

[PATCH v4 28/52] docs: remove sound API duplication
by Mauro Carvalho Chehab 30 Sep '20

30 Sep '20

The sound API is documented on two different parts: under Documentation/driver-api/sound.rst and under Documentation/sound/kernel-api/alsa-driver-api.rst. The alsa-driver-api.rst seems more complete, and APIs are split per type. There's just one missing kernel-doc markup there. Add it and drop the duplicated one. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> --- Documentation/driver-api/index.rst | 1 - Documentation/driver-api/sound.rst | 54 ------------------- .../sound/kernel-api/alsa-driver-api.rst | 1 + 3 files changed, 1 insertion(+), 55 deletions(-) delete mode 100644 Documentation/driver-api/sound.rst diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 6e7c702e0268..987d6e74ea6a 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -27,7 +27,6 @@ available subsections can be seen below. component message-based infiniband - sound frame-buffer regulator iio/index diff --git a/Documentation/driver-api/sound.rst b/Documentation/driver-api/sound.rst deleted file mode 100644 index afef6eabc073..000000000000 --- a/Documentation/driver-api/sound.rst +++ /dev/null @@ -1,54 +0,0 @@ -Sound Devices -============= - -.. kernel-doc:: include/sound/core.h - :internal: - -.. kernel-doc:: sound/sound_core.c - :export: - -.. kernel-doc:: include/sound/pcm.h - :internal: - -.. kernel-doc:: sound/core/pcm.c - :export: - -.. kernel-doc:: sound/core/device.c - :export: - -.. kernel-doc:: sound/core/info.c - :export: - -.. kernel-doc:: sound/core/rawmidi.c - :export: - -.. kernel-doc:: sound/core/sound.c - :export: - -.. kernel-doc:: sound/core/memory.c - :export: - -.. kernel-doc:: sound/core/pcm_memory.c - :export: - -.. kernel-doc:: sound/core/init.c - :export: - -.. kernel-doc:: sound/core/isadma.c - :export: - -.. kernel-doc:: sound/core/control.c - :export: - -.. kernel-doc:: sound/core/pcm_lib.c - :export: - -.. kernel-doc:: sound/core/hwdep.c - :export: - -.. kernel-doc:: sound/core/pcm_native.c - :export: - -.. kernel-doc:: sound/core/memalloc.c - :export: - diff --git a/Documentation/sound/kernel-api/alsa-driver-api.rst b/Documentation/sound/kernel-api/alsa-driver-api.rst index c8cc651eccf7..d24c64df7069 100644 --- a/Documentation/sound/kernel-api/alsa-driver-api.rst +++ b/Documentation/sound/kernel-api/alsa-driver-api.rst @@ -132,3 +132,4 @@ ISA DMA Helpers Other Helper Macros ------------------- .. kernel-doc:: include/sound/core.h +.. kernel-doc:: sound/sound_core.c -- 2.26.2

2 1

[PATCH v2 0/2] regmap: add support to regmap_field_bulk_alloc/free
by Srinivas Kandagatla 30 Sep '20

30 Sep '20

Usage of regmap_field_alloc becomes much overhead when number of fields exceed more than 3. Most of driver seems to totally covered up with these allocs/free making to very hard to read the code! On such driver is QCOM LPASS driver has extensively converted to use regmap_fields. This patchset add this new api and a user of it. Using new bulk api to allocate fields makes it much more cleaner code to read! Changes since v1: - Fix lot of spelling! No code changes! Srinivas Kandagatla (2): regmap: add support to regmap_field_bulk_alloc/free apis ASoC: lpass-platform: use devm_regmap_field_bulk_alloc drivers/base/regmap/regmap.c | 100 ++++++++++++++++++++++++++++++++ include/linux/regmap.h | 11 ++++ sound/soc/qcom/lpass-platform.c | 31 +++------- 3 files changed, 118 insertions(+), 24 deletions(-) -- 2.21.0

3 8

[PATCH -next] ASoC: soc-core: use devm_snd_soc_register_card()
by Qinglang Miao 30 Sep '20

30 Sep '20

Using devm_snd_soc_register_card() can make the code shorter and cleaner. Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> --- sound/soc/soc-core.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 74df22486..ea3986a46 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1994,16 +1994,7 @@ static int soc_probe(struct platform_device *pdev) /* Bodge while we unpick instantiation */ card->dev = &pdev->dev; - return snd_soc_register_card(card); -} - -/* removes a socdev */ -static int soc_remove(struct platform_device *pdev) -{ - struct snd_soc_card *card = platform_get_drvdata(pdev); - - snd_soc_unregister_card(card); - return 0; + return devm_snd_soc_register_card(&pdev->dev, card); } int snd_soc_poweroff(struct device *dev) @@ -2047,7 +2038,6 @@ static struct platform_driver soc_driver = { .pm = &snd_soc_pm_ops, }, .probe = soc_probe, - .remove = soc_remove, }; /** -- 2.23.0

2 1

[PATCH] ALSA: hda/ca0132: Move unsol callback setups to parser
by Takashi Iwai 30 Sep '20

30 Sep '20

The setup of unsolicited event callbacks should be done only once at the parser phase, not in the init phase that is called multiple times at each resume. This patch moves the unsol setup code in ca0132 codec driver to the more appropriate place. Reported-by: Hui Wang <hui.wang(a)canonical.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_ca0132.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c index 9779978e4bc7..2e3ae9975946 100644 --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -8538,7 +8538,7 @@ static void amic_callback(struct hda_codec *codec, struct hda_jack_callback *cb) ca0132_select_mic(codec); } -static void ca0132_init_unsol(struct hda_codec *codec) +static void ca0132_setup_unsol(struct hda_codec *codec) { struct ca0132_spec *spec = codec->spec; snd_hda_jack_detect_enable_callback(codec, spec->unsol_tag_hp, hp_callback); @@ -9368,7 +9368,6 @@ static int ca0132_init(struct hda_codec *codec) if (ca0132_quirk(spec) == QUIRK_AE5 || ca0132_quirk(spec) == QUIRK_AE7) ae5_register_set(codec); - ca0132_init_unsol(codec); ca0132_init_params(codec); ca0132_init_flags(codec); @@ -9933,6 +9932,8 @@ static int patch_ca0132(struct hda_codec *codec) if (err < 0) goto error; + ca0132_setup_unsol(codec); + return 0; error: -- 2.16.4

1 0

[PATCH] ALSA: hda - Don't register a cb func if it is registered already
by Hui Wang 30 Sep '20

30 Sep '20

If the caller of enable_callback_mst() passes a cb func, the callee function will malloc memory and link this cb func to the list unconditionally. This will introduce problem if caller is in the hda_codec_ops.init() since the init() will be repeatedly called in the codec rt_resume(). So far, the patch_hdmi.c and patch_ca0132.c call enable_callback_mst() in the hda_codec_ops.init(). Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/hda_jack.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c index 02cc682caa55..ded4813f8b54 100644 --- a/sound/pci/hda/hda_jack.c +++ b/sound/pci/hda/hda_jack.c @@ -275,6 +275,18 @@ int snd_hda_jack_detect_state_mst(struct hda_codec *codec, } EXPORT_SYMBOL_GPL(snd_hda_jack_detect_state_mst); +static bool func_is_already_in_callback_list(struct hda_jack_tbl *jack, + hda_jack_callback_fn func) +{ + struct hda_jack_callback *cb; + + for (cb = jack->callback; cb; cb = cb->next) { + if (cb->func == func) + return true; + } + return false; +} + /** * snd_hda_jack_detect_enable_mst - enable the jack-detection * @codec: the HDA codec @@ -297,7 +309,7 @@ snd_hda_jack_detect_enable_callback_mst(struct hda_codec *codec, hda_nid_t nid, jack = snd_hda_jack_tbl_new(codec, nid, dev_id); if (!jack) return ERR_PTR(-ENOMEM); - if (func) { + if (func && !func_is_already_in_callback_list(jack, func)) { callback = kzalloc(sizeof(*callback), GFP_KERNEL); if (!callback) return ERR_PTR(-ENOMEM); -- 2.17.1

3 5

Problem with sequencer interface -possible bug?
by Phillip Andrews 30 Sep '20

30 Sep '20

Hello, I've been writing an application working with ALSA's MIDI sequencer middleware, and I've been trying to abort playback of a MIDI file by calling snd_seq_reset_pool_output followed by snd_sync_output_queue. The hardware device (a player piano in my case) is silenced, but snd_sync_output_queue still blocks for roughly the amount of time it *would* have taken for all the events to be played out - almost as if there are "zombie" events that don't play, but are still pushed out according to their timing. I realize this is a thing with little to no use, and therefore little to no developer attention, but I'm desperately trying to improve the possibilities for hardware MIDI file playback on Linux. Is this something someone would be remotely interested in exploring? Thanks, Phillip A.

1 0

[PATCH] ASoC: pxa: remove unnecessary assignment to variable ret
by Jing Xiangfeng 30 Sep '20

30 Sep '20

ret is always zero here in this code path. So remove this assignment. Signed-off-by: Jing Xiangfeng <jingxiangfeng(a)huawei.com> --- sound/arm/pxa2xx-ac97.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/arm/pxa2xx-ac97.c b/sound/arm/pxa2xx-ac97.c index ea8e233150c8..813e608dca82 100644 --- a/sound/arm/pxa2xx-ac97.c +++ b/sound/arm/pxa2xx-ac97.c @@ -210,7 +210,6 @@ static int pxa2xx_ac97_pcm_new(struct snd_card *card) goto out; pxa2xx_ac97_pcm = pcm; - ret = 0; out: return ret; -- 2.17.1

1 0

bdw-rt5677: add SOF support
by GitHub pull_request - edited 29 Sep '20

29 Sep '20

alsa-project/alsa-ucm-conf pull request #53 was edited from caseorum: I believe this is the mechanism intended in 898602208888da63d758ff3c293b5ad2ec6e6c19. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/53 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/53.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

bdw-rt5677: add SOF support
by GitHub pull_request - edited 29 Sep '20

29 Sep '20

alsa-project/alsa-ucm-conf pull request #53 was edited from caseorum: I believe this is the "mechanism" intended in 898602208888da63d758ff3c293b5ad2ec6e6c19. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/53 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/53.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

bdw-rt5677: add SOF support
by GitHub pull_request - opened 29 Sep '20

29 Sep '20

alsa-project/alsa-ucm-conf pull request #53 was opened from caseorum: Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/53 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/53.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH v9 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point
by Cezary Rojewski 29 Sep '20

29 Sep '20

Implement support for Lynxpoint and Wildcat Point AudioDSP. Catpt solution deprecates existing sound/soc/intel/haswell which is removed in the following series. Due to high range of errors and desynchronization from recommendations set by Windows solution, re-write came as a lower-cost solution compared to refactoring /haswell/ with several series of patches. Series is dependent on linux-spi change: spi: pxa2xx: Add SSC2 and SSPSP2 SSP registers https://www.spinics.net/lists/linux-spi/msg23885.html which has been already merged and is now part of linux-spi tree. Bulk of series content is device driver core code - everything up to patch 7/14 - with fs entries and trace macros introduced right after. While each core patch is shaped in such a way that no unavailable members are ever called, until patch 14/14 is applied, no code compilation can occur as no Makefile is present. Once said patch is added, Makefile and Kconfig are implemented and driver module compiles as expected. Special thanks go to Marcin Barlik and Piotr Papierkowski for sharing their LPT/WPT AudioDSP architecture expertise as well as helping backtrack its historical background. My thanks go to Amadeusz Slawinski for reviews and improvements proposed on and off the internal list. Most of internal diff below is his contribution. Krzysztof Hejmowski helped me setup my own Xtensa environment and recompile LPT/WPT FW binary sources what sped up the development greatly. This would not have been possible without help from these champions, especially considering how quickly the catpt was written: 2 weeks features, 3 weeks optimizations. Thank you. Userspace-exposed members are compatible with what is exposed by deprecated solution as well as FW binary being re-used thus no harm is done. The only visible differences are: the newly added 'Loopback Mute' kcontrol and volume support extending to quad from stereo. On top of fixing erros and design flows, catpt also adds module reload, dynamic SRAM memory allocation during PCM runtime and exposes missing userspace API: 'Loopback Mute' kcontrol, quad volume controls and sysfs fw-version entries. Event tracing is provided to ease solution debugging. Following are not included in this update and are scheduled as later addition: - fw logging - module (library) support Note: LPT power up/down sequences might get aligned with WPT once enough testing is done as capabilities are shared for both DSPs. Note #2: Both LPT and WPT power up/down sequences may get optimized in future updates as thanks to help from the Windows team, most of nuances behind why/what/when in regard to hw registers have been backtracked and reviewed again. Link to developer's deep dive message: https://www.spinics.net/lists/alsa-devel/msg113563.html Changes in v9: - fixed newlines in sysfs as requested by Andy, left tags as no other changes done - removed volume_map and replaced by simple formulas for volume kcontrol calculations - removed redundant parentheses in catpt_get_channel_map() and relocated DUAL_MONO case - runtime suspend no longer called during module unload - removed redundant size checks for catpt_dsp_send_tx() and catpt_dsp_copy_rx() Changes in v8: https://www.spinics.net/lists/alsa-devel/msg116168.html - updated catpt_arrange_page_table() with GENMASK and U32_MAX usage - made use of PFN_DOWN() replacing explicit right shitfs by PAGE_SIZE - made fw hash dumping in catpt_coredump() more readable and removed hardcodes - catpt_coredump() dumps fw hash now only if said segment has been found within fw_info - shortened _MSECS suffixes to _MS - IPC structs no longer contain enum members - simplified definition of catpt_set_dspvol() Changes in v7: https://www.spinics.net/lists/alsa-devel/msg116019.html - fixed licence header for fs.c - renamed fs.c to sysfs.c to better match its purpose - added documentation within Documentation/ABI/testing for entries exposed by catpt - bin_attribute fw_build replaced by attribute fw_info: fw_info contains full FW information and after successful handshake, it's always available (stored in driver data) so no need to invoke GET_FW_VERSION IPC again, just dump the stored information - rather than manually creating and removing sysfs files, now makes use of dev_groups member of struct device_driver - patch: 10/14 'ASoC: Intel: Select catpt and deprecate haswell' has been moved to the back of the list: enable catpt after machine boards have been prepared for it first - improved readability of several goto labels Changes in v6: https://www.spinics.net/lists/alsa-devel/msg115765.html - reordered and reorganized code for patches 1/13 - 8/13 of v5, so each patches makes use of no member or function which is unavailable to it. Series size increased from 13 to 14 patches: addition of base members e.g.: registers has been split from addition of device.c file which describes acpi device behavior Changes in v5: https://www.spinics.net/lists/alsa-devel/msg115621.html Basically everything below is result of Andy's review. Thank you Andy for taking time into this detailed review - catpt now makes use of common linux/pxa2xx_ssp.h header file, removing redundant SSP register declarations in the process. As stated in the opening, this is dependent upon linux-spi change: spi: pxa2xx: Add SSC2 and SSPSP2 SSP registers - updated Kconfig by removing DMADEVICES and adding COMPILE_TEST as optional depends-on - updated all register macros definitions to be more safe against common arithmetics when specifying macro's parameters - removed CONFIG_PM and CONFIG_PM_SLEEP usage in favor of __maybe_unused - all 'if (ret < 0)' converted to simple 'if (ret)' whenever possible - fixed erroneous check for platform_device_register_data within catpt_register_board() - _SLAVE/_MASTER replaced with more inclusive _CONSUMER/_PROVIDER for enum catpt_ssp_mode - catpt_acpi_probe() is now making use of high-level wrappers for ioremapping and resource assignment, reducing function's code size - due to improved catpt_acpi_probe() behavior, catpt_acpi_remove() needs not to cast dma_free_coherent() any longer - DMA source and destrination maxburst now of value 16, see: https://www.spinics.net/lists/alsa-devel/msg114394.html - simplified catpt_dsp_update_lpclock() as list_for_each_entry() is empty-safe by default - dropped '_SSP_' from all names of all CATPT_SSP_SSXXX_DEFAULT macros - catpt_updatel_pci now makes use of linux/pci.h and uapi/linux/pci.h constants such as: PCI_PM_CTRL_STATE_MASK and PCI_D3hot Changes in v4: https://www.spinics.net/lists/alsa-devel/msg113762.html - fixed compilation with i386 kconfig (conflicting names) - streamlined naming for SHIM and PCI registers to match SSP ones (SHIM_REG -> SHIM) - catpt_component_probe removed and kcontrols again initializzed statically via snd_kcontrol_new array: this is to remove kctl->id.device shenanigans - renamed catpt_set_ctlvol to catpt_set_dspvol - function name wasn't matching its purpose Changes in v3: - fixed IRAM mask usage in lpt_dsp_power_up (dsp.c) - updated dbg message formatting in catpt_restore_fwimage as suggested by Andy - fixed alignment for struct catpt_ssp_device_format - catpt_set_ctlvol now verifies all-equal scenario based on all channels rather than just first two as requested by Amadeo - fixed SPDX for registers.h Changes in v2: https://www.spinics.net/lists/alsa-devel/msg113660.html - fixed SPDX formatting for all header files as well as pcm.c - fixed size provided to memcpy() in fw_build_read() as reported by Mark - renamed struct catpt_pdata to struct catpt_spec (cosmetic) - fixed erroneous path in catpt_load_block: region is properly released - trace.h events for updating registers have been removed and usages replaced by dev_dbg (SRAMPGE/ LPCS) - as requested by Andy, struct resource has replaced struct catpt_mbank and struct catpt_mregion. This change cascaded into: - catpt_mbank_size and catpt_mregion_size replaced by resource_size - catpt_mregion_intersects replaced by resource_overlaps - all catpt_mbank_ and catpt_mregion_ handlers found in loader.c (_request, _reserve, _release, _extract, _split, _join) have been removed - __request_region and __release_region have been enlisted in their place - catpt_mregion_intersecting renamed to catpt_resource_overlapping - catpt_request_region helper has been provided to deal with -size based requests o haven't found direct replacements in resource.c/ ioport.h for both functions - catpt_mbank_create and catpt_mbank_remove renamed to catpt_sram_init and catpt_sram_free respectively - catpt_sram_init now returns void instead of int and has been converted to simple initialized. This change ultimately cascaded into: o both SRAM banks initialization being moved to catpt_dev_init from catpt_acpi_probe (device.c) o catpt_dev::spec is now initialized first, with catpt_dev_init following it soon after o catpt_acpi_probe erroneous path has been simplified as SRAM banks no longer need to be freed - catpt_sram_free now frees all resources via child -> sibling enumeration rather than region_list iteration - catpt_dsp_update_srampge and catpt_dsp_set_srampge now accept new argument: unsigned long mask. Caused by removal of catpt_mbank - mask is taken directly from catpt_dev::spec::d/iram_mask - trace.h events for catpt_mbank and catpt_mregion have been removed Diff against last drop on internal list: https://www.spinics.net/lists/alsa-devel/msg113549.html - replaced spinlock with mutex for mregion allocation and release to address sleeping in atomic context warnings - fixed coredump fw_hash dumping - kcontrol values are now always stored regardless of stream of interest is running or not - kcontrol values are now applied after stream is prepared instead of ignoring what has been set by user initially - catpt_pdata instances have been renamed from hsw_ and bdw_ to lpt_ and wpt_ respectively - reordered Makefile .o(s) (cosmetic) Cezary Rojewski (14): ASoC: Intel: Add catpt base members ASoC: Intel: catpt: Implement IPC protocol ASoC: Intel: catpt: Add IPC message handlers ASoC: Intel: catpt: Define DSP operations ASoC: Intel: catpt: Firmware loading and context restore ASoC: Intel: catpt: PCM operations ASoC: Intel: catpt: Device driver lifecycle ASoC: Intel: catpt: Event tracing ASoC: Intel: catpt: Simple sysfs attributes ASoC: Intel: haswell: Remove haswell-solution specific code ASoC: Intel: broadwell: Remove haswell-solution specific code ASoC: Intel: bdw-5650: Remove haswell-solution specific code ASoC: Intel: bdw-5677: Remove haswell-solution specific code ASoC: Intel: Select catpt and deprecate haswell .../ABI/testing/sysfs-bus-pci-devices-catpt | 16 + sound/soc/intel/Kconfig | 24 +- sound/soc/intel/Makefile | 2 +- sound/soc/intel/boards/Kconfig | 8 +- sound/soc/intel/boards/bdw-rt5650.c | 36 - sound/soc/intel/boards/bdw-rt5677.c | 33 - sound/soc/intel/boards/broadwell.c | 33 - sound/soc/intel/boards/haswell.c | 28 +- sound/soc/intel/catpt/Makefile | 6 + sound/soc/intel/catpt/core.h | 188 +++ sound/soc/intel/catpt/device.c | 352 +++++ sound/soc/intel/catpt/dsp.c | 578 ++++++++ sound/soc/intel/catpt/ipc.c | 297 +++++ sound/soc/intel/catpt/loader.c | 671 ++++++++++ sound/soc/intel/catpt/messages.c | 313 +++++ sound/soc/intel/catpt/messages.h | 401 ++++++ sound/soc/intel/catpt/pcm.c | 1175 +++++++++++++++++ sound/soc/intel/catpt/registers.h | 178 +++ sound/soc/intel/catpt/sysfs.c | 55 + sound/soc/intel/catpt/trace.h | 83 ++ 20 files changed, 4334 insertions(+), 143 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-catpt create mode 100644 sound/soc/intel/catpt/Makefile create mode 100644 sound/soc/intel/catpt/core.h create mode 100644 sound/soc/intel/catpt/device.c create mode 100644 sound/soc/intel/catpt/dsp.c create mode 100644 sound/soc/intel/catpt/ipc.c create mode 100644 sound/soc/intel/catpt/loader.c create mode 100644 sound/soc/intel/catpt/messages.c create mode 100644 sound/soc/intel/catpt/messages.h create mode 100644 sound/soc/intel/catpt/pcm.c create mode 100644 sound/soc/intel/catpt/registers.h create mode 100644 sound/soc/intel/catpt/sysfs.c create mode 100644 sound/soc/intel/catpt/trace.h -- 2.17.1

4 26

HDA-Intel UCM crux
by Takashi Iwai 29 Sep '20

29 Sep '20

Hi Jaroslav, it seems that the recent addition of HDA-Intel.conf in ucm2 caused a regression on our CI tests on KVM. Namely, when this UCM profile is used for a plain HD-audio device on KVM, the device remains muted as default at the fresh desktop start up. Without a UCM profile, PA properly unmutes and raises the volume, but with a profile, it won't. When the volume was once saved in the pulse local config, it seems restored, though. The tested environment was KDE. Could you take a look at it? thanks, Takashi

2 1

[ANNOUNCE] SOF v1.6-rc3 released
by Liam Girdwood 29 Sep '20

29 Sep '20

The SOF developers are pleased to announce the release of our first signed release candidate for v1.6. i.e v1.6-rc3 Binaries can be found here. https://github.com/thesofproject/sof-bin/tree/stable-v1.6 New features are * Support for Intel Tigerlake * Support for Maxim Smart Amplifiers * Beamformer Microphone support. * DC blocker audio processing component. * Major feature and performance improvements for ASRC, KWD and FIR/IIR. * Numerous bug fixes and performance improvements for Intel and NXP platforms. In a change from the previous release process, the later release candidates will now be signed by Intel so that users can have the chance to test drive prior to v1.6 final. This will also give distributions more time to integrate and resolve any issues. Firmware issues can be reported here. https://github.com/thesofproject/sof/issues Thanks Liam

1 0

Re: BUG: unable to handle kernel paging request in dqput
by Takashi Iwai 29 Sep '20

29 Sep '20

On Sat, 26 Sep 2020 22:48:15 +0200, syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit: 98477740 Merge branch 'rcu/urgent' of git://git.kernel.org.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=17930875900000 > kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc > dashboard link: https://syzkaller.appspot.com/bug?extid=f816042a7ae2225f25ba > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=133783ab900000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13bb5973900000 > > The issue was bisected to: > > commit 1d0f953086f090a022f2c0e1448300c15372db46 > Author: Ioan-Adrian Ratiu <adi(a)adirat.com> > Date: Wed Jan 4 22:37:46 2017 +0000 > > ALSA: usb-audio: Fix irq/process data synchronization > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=133362c3900000 > final oops: https://syzkaller.appspot.com/x/report.txt?x=10b362c3900000 > console output: https://syzkaller.appspot.com/x/log.txt?x=173362c3900000 This commit looks really irrelevant from the Oops code path. It must be a different reason. thanks, Takashi > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+f816042a7ae2225f25ba(a)syzkaller.appspotmail.com > Fixes: 1d0f953086f0 ("ALSA: usb-audio: Fix irq/process data synchronization") > > EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue > Quota error (device loop0): qtree_write_dquot: Error -1622674347 occurred while creating quota > Quota error (device loop0): dq_insert_tree: Quota tree root isn't allocated! > Quota error (device loop0): qtree_write_dquot: Error -5 occurred while creating quota > BUG: unable to handle page fault for address: fffffbfff3e8feac > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 21ffe5067 P4D 21ffe5067 PUD 21ffe4067 PMD 0 > Oops: 0000 [#1] PREEMPT SMP KASAN > CPU: 1 PID: 6845 Comm: syz-executor636 Not tainted 5.9.0-rc6-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:91 [inline] > RIP: 0010:memory_is_nonzero mm/kasan/generic.c:108 [inline] > RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:134 [inline] > RIP: 0010:memory_is_poisoned mm/kasan/generic.c:165 [inline] > RIP: 0010:check_memory_region_inline mm/kasan/generic.c:183 [inline] > RIP: 0010:check_memory_region+0x80/0x2f0 mm/kasan/generic.c:192 > Code: 01 00 00 00 00 fc ff df 4d 01 ea 4d 89 d6 4d 29 ce 49 83 fe 10 7f 2d 4d 85 f6 0f 84 ab 01 00 00 4c 89 cb 4c 29 d3 0f 1f 40 00 <45> 0f b6 19 45 84 db 0f 85 f3 01 00 00 49 ff c1 48 ff c3 75 eb e9 > RSP: 0018:ffffc90001fdf9d0 EFLAGS: 00010293 > RAX: 2234ff0efb3ccc01 RBX: fffffffffffffffe RCX: ffffffff81e00c97 > RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff9f47f565 > RBP: ffffffff9f47f455 R08: dffffc0000000000 R09: fffffbfff3e8feac > R10: fffffbfff3e8feae R11: 0000000000000000 R12: 1ffffffff3e8feac > R13: dffffc0000000001 R14: 0000000000000002 R15: ffffffff9f47f565 > FS: 00000000009ac880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: fffffbfff3e8feac CR3: 000000009f30a000 CR4: 00000000001506e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > instrument_atomic_read include/linux/instrumented.h:56 [inline] > atomic_read include/asm-generic/atomic-instrumented.h:27 [inline] > dqput+0x77/0x770 fs/quota/dquot.c:770 > dqput_all fs/quota/dquot.c:397 [inline] > __dquot_initialize+0x9e6/0xc30 fs/quota/dquot.c:1530 > ext4_xattr_set+0x9b/0x300 fs/ext4/xattr.c:2474 > __vfs_setxattr+0x3be/0x400 fs/xattr.c:177 > __vfs_setxattr_noperm+0x11e/0x4b0 fs/xattr.c:208 > vfs_setxattr+0xde/0x270 fs/xattr.c:283 > setxattr+0x167/0x350 fs/xattr.c:548 > path_setxattr+0x109/0x1c0 fs/xattr.c:567 > __do_sys_setxattr fs/xattr.c:582 [inline] > __se_sys_setxattr fs/xattr.c:578 [inline] > __x64_sys_setxattr+0xb7/0xd0 fs/xattr.c:578 > do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x4447e9 > Code: 8d d7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b d7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:00007ffcd4905408 EFLAGS: 00000246 ORIG_RAX: 00000000000000bc > RAX: ffffffffffffffda RBX: 0030656c69662f2e RCX: 00000000004447e9 > RDX: 0000000000000000 RSI: 0000000020000140 RDI: 00000000200000c0 > RBP: 00000000006cf018 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004023d0 > R13: 0000000000402460 R14: 0000000000000000 R15: 0000000000000000 > Modules linked in: > CR2: fffffbfff3e8feac > ---[ end trace a52409661d306995 ]--- > RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:91 [inline] > RIP: 0010:memory_is_nonzero mm/kasan/generic.c:108 [inline] > RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:134 [inline] > RIP: 0010:memory_is_poisoned mm/kasan/generic.c:165 [inline] > RIP: 0010:check_memory_region_inline mm/kasan/generic.c:183 [inline] > RIP: 0010:check_memory_region+0x80/0x2f0 mm/kasan/generic.c:192 > Code: 01 00 00 00 00 fc ff df 4d 01 ea 4d 89 d6 4d 29 ce 49 83 fe 10 7f 2d 4d 85 f6 0f 84 ab 01 00 00 4c 89 cb 4c 29 d3 0f 1f 40 00 <45> 0f b6 19 45 84 db 0f 85 f3 01 00 00 49 ff c1 48 ff c3 75 eb e9 > RSP: 0018:ffffc90001fdf9d0 EFLAGS: 00010293 > RAX: 2234ff0efb3ccc01 RBX: fffffffffffffffe RCX: ffffffff81e00c97 > RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff9f47f565 > RBP: ffffffff9f47f455 R08: dffffc0000000000 R09: fffffbfff3e8feac > R10: fffffbfff3e8feae R11: 0000000000000000 R12: 1ffffffff3e8feac > R13: dffffc0000000001 R14: 0000000000000002 R15: ffffffff9f47f565 > FS: 00000000009ac880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: fffffbfff3e8feac CR3: 000000009f30a000 CR4: 00000000001506e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkaller(a)googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > syzbot can test patches for this issue, for details see: > https://goo.gl/tpsmEJ#testing-patches >

2 1

[PATCH v7 0/6] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
by Srinivasa Rao Mandadapu 29 Sep '20

29 Sep '20

These patches are to support audio over DP port on Qualcomm's SC7180 LPASS Asoc. It includes machine driver, cpu driver, platform driver updates for HDMI path support, device tree documention, lpass variant structure optimization and configuration changes. These patches depends on the DP patch series https://patchwork.kernel.org/project/dri-devel/list/?series=332029 https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 changes since V6: -- Removed compile time define flag, which used for enabling HDMI code, based on corresponding config param is included. -- Updated reg map alloc API with reg map bulk API. -- Removed unnecessary line splits changes since V5: -- Removed unused struct regmap *map in lpass_platform_alloc_hdmidmactl_fields. -- DMA alloc and free API signature change in lpass-apq8016.c, lpass-ipq806x.c -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro Changes Since v4: -- Updated with single compatible node for both I2S and HDMI. Changes Since v3: -- Removed id in lpass variant structure and used snd_soc_dai_driver id. Changes Since v2: -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in lpass-platform.c increased. Changes Since v1: -- Commit messages are updated -- Addressed Rob Herring review comments V Sujith Kumar Reddy (6): ASoC: Add sc7180-lpass binding header hdmi define ASoC: dt-bindings: Add dt binding for lpass hdmi Asoc:qcom:lpass-cpu:Update dts property read API Asoc: qcom: lpass:Update lpaif_dmactl members order ASoC: qcom: Add support for lpass hdmi driver ASoC: qcom: sc7180: Add support for audio over DP .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 +++- include/dt-bindings/sound/sc7180-lpass.h | 1 + sound/soc/qcom/Kconfig | 17 + sound/soc/qcom/Makefile | 2 + sound/soc/qcom/lpass-apq8016.c | 4 +- sound/soc/qcom/lpass-cpu.c | 55 ++- sound/soc/qcom/lpass-hdmi.c | 470 +++++++++++++++++++++ sound/soc/qcom/lpass-hdmi.h | 122 ++++++ sound/soc/qcom/lpass-ipq806x.c | 4 +- sound/soc/qcom/lpass-lpaif-reg.h | 52 ++- sound/soc/qcom/lpass-platform.c | 421 ++++++++++++++---- sound/soc/qcom/lpass-sc7180.c | 116 ++++- sound/soc/qcom/lpass.h | 119 +++++- 13 files changed, 1301 insertions(+), 156 deletions(-) create mode 100644 sound/soc/qcom/lpass-hdmi.c create mode 100644 sound/soc/qcom/lpass-hdmi.h -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

2 10

[PATCH 0/3] alsa-lib/ASoC: use inclusive language for bclk/fsync/topology
by Pierre-Louis Bossart 29 Sep '20

29 Sep '20

The SOF (Sound Open Firmware) tree contains a lot of references in topology files to 'codec_slave'/'codec_master' terms, which in turn come from alsa-lib and ALSA/ASoC topology support at the kernel level. These terms are no longer compatible with the guidelines adopted by the kernel community [1] and need to change in backwards-compatible ways. The main/secondary terms typically suggested in guidelines don't mean anything for clocks, this patchset suggests instead the use of 'provider' and 'consumer' terms, with the 'codec' prefix kept to make it clear that the codec is the reference. The CM/CS suffixes are also replaced by CP/CC. It can be argued that the change of suffix is invasive, but finding a replacement that keeps the M and S shortcuts has proven difficult in quite a few contexts. The previous definitions are kept for backwards-compatibility so this change should not have any functional impact. It is suggested that new contributions only use the new terms but there is no requirement to transition immediately to the new definitions for existing code. Intel will however update all its past contributions related to bit clock/frame sync configurations immediately. This suggestion is easier to review first at the alsa-lib level, and if agreed follow-up contributions for the Linux kernel [2] and SOF firmware [3] will be provided. Feedback welcome ~Pierre [1] https://lkml.org/lkml/2020/7/4/229 [2] https://github.com/plbossart/sound/tree/fix/inclusive-language-bclk-fsync [3] https://github.com/plbossart/sof/tree/fix/inclusive-language-bclk-fsync Changes since RFC: replaced 'follower' by 'consumer' as suggested by Jaroslav and Marc minor cleanups Pierre-Louis Bossart (3): topology: use inclusive language for bclk topology: use inclusive language for fsync topology: use inclusive language in documentation include/sound/uapi/asoc.h | 22 +++++++----- include/topology.h | 8 ++--- src/topology/pcm.c | 75 +++++++++++++++++++++++++++------------ 3 files changed, 71 insertions(+), 34 deletions(-) -- 2.25.1

2 5

UCM fails if driver built into kernel
by GitHub issues - opened 29 Sep '20

29 Sep '20

alsa-project/alsa-ucm-conf issue #52 was opened from caseorum: Since `class/sound/card${CardNumber}/device/driver/module` does not exist if the module is built-in, `${sys:$KernelModulePath}` is left undefined. This is caused by b3531451db3b4ac6aa8c6a8bec3992bcf30fffe4. The fallback suggested in alsa-project/alsa-lib#79 works for at least my bdw-rt5677. Is there a more general solution here? Maybe `.../device/modalias`? Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/52 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

RE: [PATCH v2 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
by Viorel Suman (OSS) 29 Sep '20

29 Sep '20

Hi Philipp, Thank you for your review, please check my comments inline. /Viorel > -----Original Message----- > From: Philipp Zabel [mailto:pza@pengutronix.de] > Sent: Tuesday, September 22, 2020 3:09 PM > To: Viorel Suman (OSS) <viorel.suman(a)oss.nxp.com> > Cc: Liam Girdwood <lgirdwood(a)gmail.com>; Mark Brown > <broonie(a)kernel.org>; Rob Herring <robh+dt(a)kernel.org>; Jaroslav Kysela > <perex(a)perex.cz>; Takashi Iwai <tiwai(a)suse.com>; Timur Tabi > <timur(a)kernel.org>; Nicolin Chen <nicoleotsuka(a)gmail.com>; Xiubo Li > <Xiubo.Lee(a)gmail.com>; Fabio Estevam <festevam(a)gmail.com>; Shengjiu > Wang <shengjiu.wang(a)gmail.com>; Viorel Suman <viorel.suman(a)nxp.com>; > Matthias Schiffer <matthias.schiffer(a)ew.tq-group.com>; Cosmin-Gabriel > Samoila <cosmin.samoila(a)nxp.com>; alsa-devel(a)alsa-project.org; > devicetree(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; linuxppc- > dev(a)lists.ozlabs.org; dl-linux-imx <linux-imx(a)nxp.com>; Viorel Suman > <viorel.suman(a)gmail.com> > Subject: Re: [PATCH v2 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver > > On Mon, Sep 21, 2020 at 10:08:11PM +0300, Viorel Suman (OSS) wrote: > > From: Viorel Suman <viorel.suman(a)nxp.com> > > > > XCVR (Audio Transceiver) is a on-chip functional module found on > > i.MX8MP. It support HDMI2.1 eARC, HDMI1.4 ARC and SPDIF. > > > > Signed-off-by: Viorel Suman <viorel.suman(a)nxp.com> > > --- > > sound/soc/fsl/Kconfig | 10 + > > sound/soc/fsl/Makefile | 2 + > > sound/soc/fsl/fsl_xcvr.c | 1343 > > ++++++++++++++++++++++++++++++++++++++++++++++ > > sound/soc/fsl/fsl_xcvr.h | 266 +++++++++ > > 4 files changed, 1621 insertions(+) > > create mode 100644 sound/soc/fsl/fsl_xcvr.c create mode 100644 > > sound/soc/fsl/fsl_xcvr.h > > > > diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index > > 3f76ff7..d04b64d 100644 > > --- a/sound/soc/fsl/Kconfig > > +++ b/sound/soc/fsl/Kconfig > > @@ -95,6 +95,16 @@ config SND_SOC_FSL_EASRC > > destination sample rate. It is a new design module compare with the > > old ASRC. > > > > +config SND_SOC_FSL_XCVR > > + tristate "NXP Audio Transceiver (XCVR) module support" > > + select REGMAP_MMIO > > + select SND_SOC_IMX_PCM_DMA if SND_IMX_SOC != n > > + select SND_SOC_GENERIC_DMAENGINE_PCM > > + help > > + Say Y if you want to add Audio Transceiver (XCVR) support for NXP > > + iMX CPUs. XCVR is a digital module that supports HDMI2.1 eARC, > > + HDMI1.4 ARC and SPDIF. > > + > > config SND_SOC_FSL_UTILS > > tristate > > > > diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile index > > b835eeb..1d2231f 100644 > > --- a/sound/soc/fsl/Makefile > > +++ b/sound/soc/fsl/Makefile > > @@ -25,6 +25,7 @@ snd-soc-fsl-utils-objs := fsl_utils.o > > snd-soc-fsl-dma-objs := fsl_dma.o snd-soc-fsl-mqs-objs := fsl_mqs.o > > snd-soc-fsl-easrc-objs := fsl_easrc.o > > +snd-soc-fsl-xcvr-objs := fsl_xcvr.o > > > > obj-$(CONFIG_SND_SOC_FSL_AUDMIX) += snd-soc-fsl-audmix.o > > obj-$(CONFIG_SND_SOC_FSL_ASOC_CARD) += snd-soc-fsl-asoc-card.o @@ > > -38,6 +39,7 @@ obj-$(CONFIG_SND_SOC_FSL_UTILS) += snd-soc-fsl-utils.o > > obj-$(CONFIG_SND_SOC_FSL_MQS) += snd-soc-fsl-mqs.o > > obj-$(CONFIG_SND_SOC_FSL_EASRC) += snd-soc-fsl-easrc.o > > obj-$(CONFIG_SND_SOC_POWERPC_DMA) += snd-soc-fsl-dma.o > > +obj-$(CONFIG_SND_SOC_FSL_XCVR) += snd-soc-fsl-xcvr.o > > > > # MPC5200 Platform Support > > obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o diff --git > > a/sound/soc/fsl/fsl_xcvr.c b/sound/soc/fsl/fsl_xcvr.c new file mode > > 100644 index 00000000..7391bca > > --- /dev/null > > +++ b/sound/soc/fsl/fsl_xcvr.c > > @@ -0,0 +1,1343 @@ > [...] > > +static int fsl_xcvr_probe(struct platform_device *pdev) { > > + struct device *dev = &pdev->dev; > > + struct device_node *np = dev->of_node; > > + const struct of_device_id *of_id; > > + struct fsl_xcvr *xcvr; > > + struct resource *ram_res, *regs_res, *rx_res, *tx_res; > > + void __iomem *regs; > > + int ret, irq; > > + > > + of_id = of_match_device(fsl_xcvr_dt_ids, dev); > > + if (!of_id) > > + return -EINVAL; > > + > > + xcvr = devm_kzalloc(dev, sizeof(*xcvr), GFP_KERNEL); > > + if (!xcvr) > > + return -ENOMEM; > > + > > + xcvr->pdev = pdev; > > + xcvr->ipg_clk = devm_clk_get(dev, "ipg"); > > + if (IS_ERR(xcvr->ipg_clk)) { > > + dev_err(dev, "failed to get ipg clock\n"); > > + return PTR_ERR(xcvr->ipg_clk); > > + } > > + > > + xcvr->phy_clk = devm_clk_get(dev, "phy"); > > + if (IS_ERR(xcvr->phy_clk)) { > > + dev_err(dev, "failed to get phy clock\n"); > > + return PTR_ERR(xcvr->phy_clk); > > + } > > + > > + xcvr->spba_clk = devm_clk_get(dev, "spba"); > > + if (IS_ERR(xcvr->spba_clk)) { > > + dev_err(dev, "failed to get spba clock\n"); > > + return PTR_ERR(xcvr->spba_clk); > > + } > > + > > + xcvr->pll_ipg_clk = devm_clk_get(dev, "pll_ipg"); > > + if (IS_ERR(xcvr->pll_ipg_clk)) { > > + dev_err(dev, "failed to get pll_ipg clock\n"); > > + return PTR_ERR(xcvr->pll_ipg_clk); > > + } > > + > > + ram_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, > "ram"); > > + xcvr->ram_addr = devm_ioremap_resource(dev, ram_res); > > + if (IS_ERR(xcvr->ram_addr)) > > + return PTR_ERR(xcvr->ram_addr); > > + > > + regs_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, > "regs"); > > + regs = devm_ioremap_resource(dev, regs_res); > > + if (IS_ERR(regs)) > > + return PTR_ERR(regs); > > + > > + xcvr->regmap = devm_regmap_init_mmio_clk(dev, NULL, regs, > > + &fsl_xcvr_regmap_cfg); > > + if (IS_ERR(xcvr->regmap)) { > > + dev_err(dev, "failed to init XCVR regmap: %ld\n", > > + PTR_ERR(xcvr->regmap)); > > + return PTR_ERR(xcvr->regmap); > > + } > > + > > + xcvr->reset = of_reset_control_get(np, NULL); > > Please use devm_reset_control_get_exclusive(). Done in V3. > > [...] > > +static __maybe_unused int fsl_xcvr_runtime_resume(struct device *dev) > > +{ > > + struct fsl_xcvr *xcvr = dev_get_drvdata(dev); > > + int ret; > > + > > + ret = clk_prepare_enable(xcvr->ipg_clk); > > + if (ret) { > > + dev_err(dev, "failed to start IPG clock.\n"); > > + return ret; > > + } > > + > > + ret = clk_prepare_enable(xcvr->pll_ipg_clk); > > + if (ret) { > > + dev_err(dev, "failed to start PLL IPG clock.\n"); > > + goto stop_ipg_clk; > > + } > > + > > + ret = clk_prepare_enable(xcvr->phy_clk); > > + if (ret) { > > + dev_err(dev, "failed to start PHY clock: %d\n", ret); > > + goto stop_pll_ipg_clk; > > + } > > + > > + ret = clk_prepare_enable(xcvr->spba_clk); > > + if (ret) { > > + dev_err(dev, "failed to start SPBA clock.\n"); > > + goto stop_phy_clk; > > + } > > + > > + regcache_cache_only(xcvr->regmap, false); > > + regcache_mark_dirty(xcvr->regmap); > > + ret = regcache_sync(xcvr->regmap); > > + > > + if (ret) { > > + dev_err(dev, "failed to sync regcache.\n"); > > + goto stop_spba_clk; > > + } > > + > > + reset_control_assert(xcvr->reset); > > + reset_control_deassert(xcvr->reset); > > No delay required between the two? Not required. Just to keep things in proper context - in V3 I moved reset_control_assert call into runtime_suspend. /Viorel

1 0

[PATCH] ALSA: hda/realtek - set mic to auto detect on a HP AIO machine
by Hui Wang 29 Sep '20

29 Sep '20

Recently we enabled a HP AIO machine, we found the mic on the machine couldn't record any sound and it couldn't detect plugging and unplugging as well. Through debugging we found the mic is set to manual detect mode, after setting it to auto detect mode, it could detect plugging and unplugging and could record sound. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index d4f17b465892..4e5809648df1 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6233,6 +6233,7 @@ enum { ALC269_FIXUP_LEMOTE_A190X, ALC256_FIXUP_INTEL_NUC8_RUGGED, ALC255_FIXUP_XIAOMI_HEADSET_MIC, + ALC274_FIXUP_HP_MIC, }; static const struct hda_fixup alc269_fixups[] = { @@ -7612,6 +7613,14 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC289_FIXUP_ASUS_GA401 }, + [ALC274_FIXUP_HP_MIC] = { + .type = HDA_FIXUP_VERBS, + .v.verbs = (const struct hda_verb[]) { + { 0x20, AC_VERB_SET_COEF_INDEX, 0x45 }, + { 0x20, AC_VERB_SET_PROC_COEF, 0x5089 }, + { } + }, + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -7763,6 +7772,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x869d, "HP", ALC236_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x8729, "HP", ALC285_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8736, "HP", ALC285_FIXUP_HP_GPIO_AMP_INIT), + SND_PCI_QUIRK(0x103c, 0x874e, "HP", ALC274_FIXUP_HP_MIC), SND_PCI_QUIRK(0x103c, 0x877a, "HP", ALC285_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x877d, "HP", ALC236_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC), @@ -8088,6 +8098,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = { {.id = ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE, .name = "alc256-medion-headset"}, {.id = ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, .name = "alc298-samsung-headphone"}, {.id = ALC255_FIXUP_XIAOMI_HEADSET_MIC, .name = "alc255-xiaomi-headset"}, + {.id = ALC274_FIXUP_HP_MIC, .name = "alc274-hp-mic-detect"}, {} }; #define ALC225_STANDARD_PINS \ -- 2.17.1

2 1

[PATCH] ASoC: rt5682: Enable the power of "MICBIAS" and "Vref2" for the DMIC clock
by Oder Chiou 28 Sep '20

28 Sep '20

The power of "MICBIAS" and "Vref2" was needed while the DMIC clcok was from the PLL output. Signed-off-by: Oder Chiou <oder_chiou(a)realtek.com> --- sound/soc/codecs/rt5682.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/rt5682.c b/sound/soc/codecs/rt5682.c index 93ebf0279b62..a9acce7b6cca 100644 --- a/sound/soc/codecs/rt5682.c +++ b/sound/soc/codecs/rt5682.c @@ -1529,16 +1529,35 @@ static int set_dmic_power(struct snd_soc_dapm_widget *w, struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm); struct rt5682_priv *rt5682 = snd_soc_component_get_drvdata(component); - unsigned int delay = 50; + unsigned int delay = 50, val; if (rt5682->pdata.dmic_delay) delay = rt5682->pdata.dmic_delay; switch (event) { case SND_SOC_DAPM_POST_PMU: + val = snd_soc_component_read(component, RT5682_GLB_CLK); + val &= RT5682_SCLK_SRC_MASK; + if (val == RT5682_SCLK_SRC_PLL1 || val == RT5682_SCLK_SRC_PLL2) + snd_soc_component_update_bits(component, + RT5682_PWR_ANLG_1, + RT5682_PWR_VREF2 | RT5682_PWR_MB, + RT5682_PWR_VREF2 | RT5682_PWR_MB); + /*Add delay to avoid pop noise*/ msleep(delay); break; + + case SND_SOC_DAPM_POST_PMD: + if (!rt5682->jack_type) { + if (!snd_soc_dapm_get_pin_status(w->dapm, "MICBIAS")) + snd_soc_component_update_bits(component, + RT5682_PWR_ANLG_1, RT5682_PWR_MB, 0); + if (!snd_soc_dapm_get_pin_status(w->dapm, "Vref2")) + snd_soc_component_update_bits(component, + RT5682_PWR_ANLG_1, RT5682_PWR_VREF2, 0); + } + break; } return 0; @@ -1644,7 +1663,8 @@ static const struct snd_soc_dapm_widget rt5682_dapm_widgets[] = { SND_SOC_DAPM_SUPPLY("DMIC CLK", SND_SOC_NOPM, 0, 0, set_dmic_clk, SND_SOC_DAPM_PRE_PMU), SND_SOC_DAPM_SUPPLY("DMIC1 Power", RT5682_DMIC_CTRL_1, - RT5682_DMIC_1_EN_SFT, 0, set_dmic_power, SND_SOC_DAPM_POST_PMU), + RT5682_DMIC_1_EN_SFT, 0, set_dmic_power, + SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD), /* Boost */ SND_SOC_DAPM_PGA("BST1 CBJ", SND_SOC_NOPM, -- 2.28.0

2 1

[PATCH v2] ASoC: rt715: Add power-up delay to fix dmic pop sound issue.
by Pierre-Louis Bossart 28 Sep '20

28 Sep '20

From: Jack Yu <jack.yu(a)realtek.com> Add 400ms power-up delay recommended to fix pop noise on capture. BugLink: https://github.com/thesofproject/linux/issues/1969 Reviewed-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)linux.intel.com> Signed-off-by: Jack Yu <jack.yu(a)realtek.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- v2: remove module parameter as suggested by Mark Brown. sound/soc/codecs/rt715.c | 2 +- sound/soc/codecs/rt715.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt715.c b/sound/soc/codecs/rt715.c index 099c8bd20006..532c5303e7ab 100644 --- a/sound/soc/codecs/rt715.c +++ b/sound/soc/codecs/rt715.c @@ -9,7 +9,6 @@ */ #include <linux/module.h> -#include <linux/moduleparam.h> #include <linux/kernel.h> #include <linux/init.h> #include <linux/delay.h> @@ -498,6 +497,7 @@ static int rt715_set_bias_level(struct snd_soc_component *component, regmap_write(rt715->regmap, RT715_SET_AUDIO_POWER_STATE, AC_PWRST_D0); + msleep(RT715_POWER_UP_DELAY_MS); } break; diff --git a/sound/soc/codecs/rt715.h b/sound/soc/codecs/rt715.h index df0f24f9bc0c..d0d0fd2a6fdb 100644 --- a/sound/soc/codecs/rt715.h +++ b/sound/soc/codecs/rt715.h @@ -210,6 +210,8 @@ enum { RT715_AIFS, }; +#define RT715_POWER_UP_DELAY_MS 400 + int rt715_io_init(struct device *dev, struct sdw_slave *slave); int rt715_init(struct device *dev, struct regmap *sdw_regmap, struct regmap *regmap, struct sdw_slave *slave); -- 2.25.1

2 1

[PATCH v2 1/2] ASoC: cs4234: Add dtschema binding document
by Richard Fitzgerald 28 Sep '20

28 Sep '20

From: Charles Keepax <ckeepax(a)opensource.cirrus.com> Document the bindings for the CS4234 ASoC codec driver. Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> --- .../bindings/sound/cirrus,cs4234.yaml | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/cirrus,cs4234.yaml diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs4234.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs4234.yaml new file mode 100644 index 000000000000..156560b2a980 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cirrus,cs4234.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/cirrus,cs4234.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic cs4234 audio CODEC + +maintainers: + - patches(a)opensource.cirrus.com + +description: + The CS4234 is a highly versatile CODEC that combines 4 channels of + high performance analog to digital conversion, 4 channels of high + performance digital to analog conversion for audio, and 1 channel of + digital to analog conversion to provide a nondelayed audio reference + signal to an external Class H tracking power supply. If not used to + drive a tracking power supply, the 5th DAC can instead be used as a + standard audio grade DAC, with performance specifications identical + to that of the 4 DACs in the audio path. Additionally, the CS4234 + includes tunable group delay for each of the 4 audio DAC paths to + provide lead time for the external switch-mode power supply, and a + nondelayed path into the DAC outputs for input signals requiring a + low-latency path to the outputs. + +properties: + compatible: + enum: + - cirrus,cs4234 + + reg: + description: + The 7-bit I2C address depends on the state of the ADx pins, in + binary given by [0 0 1 0 AD2 AD1 AD0 0]. + items: + minimum: 0x10 + maximum: 0x17 + + VA-supply: + description: + Analogue power supply. + + VL-supply: + description: + Interface power supply. + + reset-gpios: + maxItems: 1 + +required: + - compatible + - reg + - VA-supply + - VL-supply + +additionalProperties: false + +examples: + - | + i2c@e0004000 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe0004000 0x1000>; + + cs4234: codec@11 { + compatible = "cirrus,cs4234"; + reg = <0x11>; + + VA-supply = <&vdd3v3>; + VL-supply = <&vdd3v3>; + + reset-gpios = <&gpio 0>; + }; + }; -- 2.20.1

2 2

[PATCH] ASoC: dt-bindings: sgtl5000: Add common clock properties
by Krzysztof Kozlowski 28 Sep '20

28 Sep '20

Add common properties appearing in DTSes (assigned-clocks and similar) to fix dtbs_check warnings like: arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dt.yaml: audio-codec@a: 'assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' do not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> --- Documentation/devicetree/bindings/sound/sgtl5000.yaml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml index 4f29b63c54d3..d116c174b545 100644 --- a/Documentation/devicetree/bindings/sound/sgtl5000.yaml +++ b/Documentation/devicetree/bindings/sound/sgtl5000.yaml @@ -19,6 +19,10 @@ properties: "#sound-dai-cells": const: 0 + assigned-clock-parents: true + assigned-clock-rates: true + assigned-clocks: true + clocks: items: - description: the clock provider of SYS_MCLK -- 2.17.1

2 1

[PATCH] ASoC: q6afe-clocks: Fix typo in SPDX Licence
by Srinivas Kandagatla 28 Sep '20

28 Sep '20

Looks like there was a major typo in SPDX Licence version, Not sure how it was missed. This patch is to fix it. Reported-by: Lukas Bulwahn <lukas.bulwahn(a)gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- sound/soc/qcom/qdsp6/q6afe-clocks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/qcom/qdsp6/q6afe-clocks.c b/sound/soc/qcom/qdsp6/q6afe-clocks.c index 25b409597d51..2efc2eaa0424 100644 --- a/sound/soc/qcom/qdsp6/q6afe-clocks.c +++ b/sound/soc/qcom/qdsp6/q6afe-clocks.c @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-1.0 +// SPDX-License-Identifier: GPL-2.0 // Copyright (c) 2020, Linaro Limited #include <linux/err.h> -- 2.21.0

2 1

[PATCH] ASoC: ti: j721e-evm: Fix compiler warning when CONFIG_OF=n
by Peter Ujfalusi 28 Sep '20

28 Sep '20

Remove the use of of_match_ptr() macro for of_match_table to fix compiler warning when CONFIG_OF=n: sound/soc/ti/j721e-evm.c:528:34: warning: unused variable 'j721e_audio_of_match' [-Wunused-const-variable] Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/ti/j721e-evm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/ti/j721e-evm.c b/sound/soc/ti/j721e-evm.c index 29b73303f3fc..a7c0484d44ec 100644 --- a/sound/soc/ti/j721e-evm.c +++ b/sound/soc/ti/j721e-evm.c @@ -895,7 +895,7 @@ static struct platform_driver j721e_soc_driver = { .driver = { .name = "j721e-audio", .pm = &snd_soc_pm_ops, - .of_match_table = of_match_ptr(j721e_audio_of_match), + .of_match_table = j721e_audio_of_match, }, .probe = j721e_soc_probe, }; -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2 1

[PATCH v2] ASoC: tegra20-spdif: remove "default m"
by Michał Mirosław 28 Sep '20

28 Sep '20

Make tegra20-spdif default to N as all other drivers do. Add the selection to defconfigs instead. Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Fixes: 774fec338bfc ("ASoC: Tegra: Implement SPDIF CPU DAI") --- v2: add the symbol to defconfig as suggested by Thierry Reding --- arch/arm/configs/multi_v7_defconfig | 1 + arch/arm/configs/tegra_defconfig | 1 + sound/soc/tegra/Kconfig | 1 - 3 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index e9e76e32f10f..19342ac738a5 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -743,6 +743,7 @@ CONFIG_SND_SOC_STM32_I2S=m CONFIG_SND_SUN4I_CODEC=m CONFIG_SND_SOC_TEGRA=m CONFIG_SND_SOC_TEGRA20_I2S=m +CONFIG_SND_SOC_TEGRA20_SPDIF=m CONFIG_SND_SOC_TEGRA30_I2S=m CONFIG_SND_SOC_TEGRA_RT5640=m CONFIG_SND_SOC_TEGRA_WM8753=m diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index fff5fae0db30..08526eb50484 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@ -225,6 +225,7 @@ CONFIG_SND_HDA_CODEC_HDMI=y CONFIG_SND_SOC=y CONFIG_SND_SOC_TEGRA=y CONFIG_SND_SOC_TEGRA20_I2S=y +CONFIG_SND_SOC_TEGRA20_SPDIF=y CONFIG_SND_SOC_TEGRA30_I2S=y CONFIG_SND_SOC_TEGRA_RT5640=y CONFIG_SND_SOC_TEGRA_WM8753=y diff --git a/sound/soc/tegra/Kconfig b/sound/soc/tegra/Kconfig index 3d91bd3e59cd..a62cc87551ac 100644 --- a/sound/soc/tegra/Kconfig +++ b/sound/soc/tegra/Kconfig @@ -39,7 +39,6 @@ config SND_SOC_TEGRA20_I2S config SND_SOC_TEGRA20_SPDIF tristate "Tegra20 SPDIF interface" depends on SND_SOC_TEGRA - default m help Say Y or M if you want to add support for the Tegra20 SPDIF interface. You will also need to select the individual machine drivers to support -- 2.20.1

1 0

[PATCH] ASoC: tegra20-spdif: remove "default m"
by Michał Mirosław 28 Sep '20

28 Sep '20

Make tegra20-spdif default to N as all other drivers do. Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl> Fixes: 774fec338bfc ("ASoC: Tegra: Implement SPDIF CPU DAI") --- sound/soc/tegra/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/tegra/Kconfig b/sound/soc/tegra/Kconfig index 3d91bd3e59cd..a62cc87551ac 100644 --- a/sound/soc/tegra/Kconfig +++ b/sound/soc/tegra/Kconfig @@ -39,7 +39,6 @@ config SND_SOC_TEGRA20_I2S config SND_SOC_TEGRA20_SPDIF tristate "Tegra20 SPDIF interface" depends on SND_SOC_TEGRA - default m help Say Y or M if you want to add support for the Tegra20 SPDIF interface. You will also need to select the individual machine drivers to support -- 2.20.1

2 2

[PATCH v3 0/2] soundwire: sysfs: expose device number and status
by Pierre-Louis Bossart 28 Sep '20

28 Sep '20

This patchset combines three contributions: Srinivas Kandagalta suggested creating a device even it's detected on the bus but not described in platform firmware. I suggested adding the device number and status to show the difference with 'ghost' devices, described in firmware but not physically present. Vinod suggested a simpler way to report the status. I did not keep Vinod's patch separate since it was using the same group attribute as the other properties, which prevents status and device number from being reported if there is no firmware and no driver. These patches were tested on Qualcomm and Intel platforms. v3: add Co-developed-by tags and move 'status' and 'device_number' to device level instead of a dev-status directory. v2: as suggested by GregKH, add attribute group by default by setting the groups pointer at the device level. Pierre-Louis Bossart (1): soundwire: sysfs: add slave status and device number before probe Srinivas Kandagatla (1): soundwire: bus: add enumerated Slave device to device list .../ABI/testing/sysfs-bus-soundwire-slave | 18 ++++++ drivers/soundwire/bus.c | 9 +++ drivers/soundwire/bus.h | 2 + drivers/soundwire/bus_type.c | 9 +++ drivers/soundwire/slave.c | 6 +- drivers/soundwire/sysfs_local.h | 4 ++ drivers/soundwire/sysfs_slave.c | 58 ++++++++++++++++++- 7 files changed, 103 insertions(+), 3 deletions(-) -- 2.25.1

3 4

[PATCH] ASoC: q6afe-clocks: Reduce code duplication via macro
by Joe Perches 27 Sep '20

27 Sep '20

The existing macro uses duplicate the index value so move the index into the macro to reduce any possible copy/paste and typo defects. Miscellanea: o Neaten macro Signed-off-by: Joe Perches <joe(a)perches.com> --- sound/soc/qcom/qdsp6/q6afe-clocks.c | 191 ++++++++++++++++++----------- ------- 1 file changed, 93 insertions(+), 98 deletions(-) diff --git a/sound/soc/qcom/qdsp6/q6afe-clocks.c b/sound/soc/qcom/qdsp6/q6afe-clocks.c index 2967f4546af5..4d897d6dad56 100644 --- a/sound/soc/qcom/qdsp6/q6afe-clocks.c +++ b/sound/soc/qcom/qdsp6/q6afe-clocks.c @@ -11,27 +11,6 @@ #include <linux/slab.h> #include "q6afe.h" -#define Q6AFE_CLK(id) &(struct q6afe_clk) { \ - .clk_id = id, \ - .afe_clk_id = Q6AFE_##id, \ - .name = #id, \ - .attributes = LPASS_CLK_ATTRIBUTE_COUPLE_NO, \ - .hw.init = &(struct clk_init_data) { \ - .ops = &clk_q6afe_ops, \ - .name = #id, \ - }, \ - } - -#define Q6AFE_VOTE_CLK(id, blkid, n) &(struct q6afe_clk) { \ - .clk_id = id, \ - .afe_clk_id = blkid, \ - .name = #n, \ - .hw.init = &(struct clk_init_data) { \ - .ops = &clk_vote_q6afe_ops, \ - .name = #id, \ - }, \ - } - struct q6afe_clk { struct device *dev; int clk_id; @@ -119,84 +98,100 @@ static const struct clk_ops clk_vote_q6afe_ops = { .unprepare = clk_unvote_q6afe_block, }; +#define Q6AFE_CLK(id) \ + [id] = &(struct q6afe_clk) { \ + .clk_id = id, \ + .afe_clk_id = Q6AFE_##id, \ + .name = #id, \ + .attributes = LPASS_CLK_ATTRIBUTE_COUPLE_NO, \ + .hw.init = &(struct clk_init_data) { \ + .ops = &clk_q6afe_ops, \ + .name = #id, \ + }, \ + } + +#define Q6AFE_VOTE_CLK(id, blkid, n) \ + [id] = &(struct q6afe_clk) { \ + .clk_id = id, \ + .afe_clk_id = blkid, \ + .name = #n, \ + .hw.init = &(struct clk_init_data) { \ + .ops = &clk_vote_q6afe_ops, \ + .name = #id, \ + }, \ + } + struct q6afe_clk *q6afe_clks[Q6AFE_MAX_CLK_ID] = { - [LPASS_CLK_ID_PRI_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_PRI_MI2S_IBIT), - [LPASS_CLK_ID_PRI_MI2S_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_PRI_MI2S_EBIT), - [LPASS_CLK_ID_SEC_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_SEC_MI2S_IBIT), - [LPASS_CLK_ID_SEC_MI2S_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_SEC_MI2S_EBIT), - [LPASS_CLK_ID_TER_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_TER_MI2S_IBIT), - [LPASS_CLK_ID_TER_MI2S_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_TER_MI2S_EBIT), - [LPASS_CLK_ID_QUAD_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUAD_MI2S_IBIT), - [LPASS_CLK_ID_QUAD_MI2S_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUAD_MI2S_EBIT), - [LPASS_CLK_ID_SPEAKER_I2S_IBIT] = - Q6AFE_CLK(LPASS_CLK_ID_SPEAKER_I2S_IBIT), - [LPASS_CLK_ID_SPEAKER_I2S_EBIT] = - Q6AFE_CLK(LPASS_CLK_ID_SPEAKER_I2S_EBIT), - [LPASS_CLK_ID_SPEAKER_I2S_OSR] = - Q6AFE_CLK(LPASS_CLK_ID_SPEAKER_I2S_OSR), - [LPASS_CLK_ID_QUI_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUI_MI2S_IBIT), - [LPASS_CLK_ID_QUI_MI2S_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUI_MI2S_EBIT), - [LPASS_CLK_ID_SEN_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_SEN_MI2S_IBIT), - [LPASS_CLK_ID_SEN_MI2S_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_SEN_MI2S_EBIT), - [LPASS_CLK_ID_INT0_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_INT0_MI2S_IBIT), - [LPASS_CLK_ID_INT1_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_INT1_MI2S_IBIT), - [LPASS_CLK_ID_INT2_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_INT2_MI2S_IBIT), - [LPASS_CLK_ID_INT3_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_INT3_MI2S_IBIT), - [LPASS_CLK_ID_INT4_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_INT4_MI2S_IBIT), - [LPASS_CLK_ID_INT5_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_INT5_MI2S_IBIT), - [LPASS_CLK_ID_INT6_MI2S_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_INT6_MI2S_IBIT), - [LPASS_CLK_ID_QUI_MI2S_OSR] = Q6AFE_CLK(LPASS_CLK_ID_QUI_MI2S_OSR), - [LPASS_CLK_ID_PRI_PCM_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_PRI_PCM_IBIT), - [LPASS_CLK_ID_PRI_PCM_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_PRI_PCM_EBIT), - [LPASS_CLK_ID_SEC_PCM_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_SEC_PCM_IBIT), - [LPASS_CLK_ID_SEC_PCM_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_SEC_PCM_EBIT), - [LPASS_CLK_ID_TER_PCM_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_TER_PCM_IBIT), - [LPASS_CLK_ID_TER_PCM_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_TER_PCM_EBIT), - [LPASS_CLK_ID_QUAD_PCM_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUAD_PCM_IBIT), - [LPASS_CLK_ID_QUAD_PCM_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUAD_PCM_EBIT), - [LPASS_CLK_ID_QUIN_PCM_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUIN_PCM_IBIT), - [LPASS_CLK_ID_QUIN_PCM_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUIN_PCM_EBIT), - [LPASS_CLK_ID_QUI_PCM_OSR] = Q6AFE_CLK(LPASS_CLK_ID_QUI_PCM_OSR), - [LPASS_CLK_ID_PRI_TDM_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_PRI_TDM_IBIT), - [LPASS_CLK_ID_PRI_TDM_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_PRI_TDM_EBIT), - [LPASS_CLK_ID_SEC_TDM_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_SEC_TDM_IBIT), - [LPASS_CLK_ID_SEC_TDM_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_SEC_TDM_EBIT), - [LPASS_CLK_ID_TER_TDM_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_TER_TDM_IBIT), - [LPASS_CLK_ID_TER_TDM_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_TER_TDM_EBIT), - [LPASS_CLK_ID_QUAD_TDM_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUAD_TDM_IBIT), - [LPASS_CLK_ID_QUAD_TDM_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUAD_TDM_EBIT), - [LPASS_CLK_ID_QUIN_TDM_IBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUIN_TDM_IBIT), - [LPASS_CLK_ID_QUIN_TDM_EBIT] = Q6AFE_CLK(LPASS_CLK_ID_QUIN_TDM_EBIT), - [LPASS_CLK_ID_QUIN_TDM_OSR] = Q6AFE_CLK(LPASS_CLK_ID_QUIN_TDM_OSR), - [LPASS_CLK_ID_MCLK_1] = Q6AFE_CLK(LPASS_CLK_ID_MCLK_1), - [LPASS_CLK_ID_MCLK_2] = Q6AFE_CLK(LPASS_CLK_ID_MCLK_2), - [LPASS_CLK_ID_MCLK_3] = Q6AFE_CLK(LPASS_CLK_ID_MCLK_3), - [LPASS_CLK_ID_MCLK_4] = Q6AFE_CLK(LPASS_CLK_ID_MCLK_4), - [LPASS_CLK_ID_INTERNAL_DIGITAL_CODEC_CORE] = - Q6AFE_CLK(LPASS_CLK_ID_INTERNAL_DIGITAL_CODEC_CORE), - [LPASS_CLK_ID_INT_MCLK_0] = Q6AFE_CLK(LPASS_CLK_ID_INT_MCLK_0), - [LPASS_CLK_ID_INT_MCLK_1] = Q6AFE_CLK(LPASS_CLK_ID_INT_MCLK_1), - [LPASS_CLK_ID_WSA_CORE_MCLK] = Q6AFE_CLK(LPASS_CLK_ID_WSA_CORE_MCLK), - [LPASS_CLK_ID_WSA_CORE_NPL_MCLK] = - Q6AFE_CLK(LPASS_CLK_ID_WSA_CORE_NPL_MCLK), - [LPASS_CLK_ID_VA_CORE_MCLK] = Q6AFE_CLK(LPASS_CLK_ID_VA_CORE_MCLK), - [LPASS_CLK_ID_TX_CORE_MCLK] = Q6AFE_CLK(LPASS_CLK_ID_TX_CORE_MCLK), - [LPASS_CLK_ID_TX_CORE_NPL_MCLK] = - Q6AFE_CLK(LPASS_CLK_ID_TX_CORE_NPL_MCLK), - [LPASS_CLK_ID_RX_CORE_MCLK] = Q6AFE_CLK(LPASS_CLK_ID_RX_CORE_MCLK), - [LPASS_CLK_ID_RX_CORE_NPL_MCLK] = - Q6AFE_CLK(LPASS_CLK_ID_RX_CORE_NPL_MCLK), - [LPASS_CLK_ID_VA_CORE_2X_MCLK] = - Q6AFE_CLK(LPASS_CLK_ID_VA_CORE_2X_MCLK), - [LPASS_HW_AVTIMER_VOTE] = Q6AFE_VOTE_CLK(LPASS_HW_AVTIMER_VOTE, - Q6AFE_LPASS_CORE_AVTIMER_BLOCK, - "LPASS_AVTIMER_MACRO"), - [LPASS_HW_MACRO_VOTE] = Q6AFE_VOTE_CLK(LPASS_HW_MACRO_VOTE, - Q6AFE_LPASS_CORE_HW_MACRO_BLOCK, - "LPASS_HW_MACRO"), - [LPASS_HW_DCODEC_VOTE] = Q6AFE_VOTE_CLK(LPASS_HW_DCODEC_VOTE, - Q6AFE_LPASS_CORE_HW_DCODEC_BLOCK, - "LPASS_HW_DCODEC"), + Q6AFE_CLK(LPASS_CLK_ID_PRI_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_PRI_MI2S_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_SEC_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_SEC_MI2S_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_TER_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_TER_MI2S_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUAD_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUAD_MI2S_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_SPEAKER_I2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_SPEAKER_I2S_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_SPEAKER_I2S_OSR), + Q6AFE_CLK(LPASS_CLK_ID_QUI_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUI_MI2S_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_SEN_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_SEN_MI2S_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_INT0_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_INT1_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_INT2_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_INT3_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_INT4_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_INT5_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_INT6_MI2S_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUI_MI2S_OSR), + Q6AFE_CLK(LPASS_CLK_ID_PRI_PCM_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_PRI_PCM_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_SEC_PCM_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_SEC_PCM_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_TER_PCM_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_TER_PCM_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUAD_PCM_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUAD_PCM_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUIN_PCM_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUIN_PCM_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUI_PCM_OSR), + Q6AFE_CLK(LPASS_CLK_ID_PRI_TDM_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_PRI_TDM_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_SEC_TDM_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_SEC_TDM_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_TER_TDM_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_TER_TDM_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUAD_TDM_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUAD_TDM_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUIN_TDM_IBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUIN_TDM_EBIT), + Q6AFE_CLK(LPASS_CLK_ID_QUIN_TDM_OSR), + Q6AFE_CLK(LPASS_CLK_ID_MCLK_1), + Q6AFE_CLK(LPASS_CLK_ID_MCLK_2), + Q6AFE_CLK(LPASS_CLK_ID_MCLK_3), + Q6AFE_CLK(LPASS_CLK_ID_MCLK_4), + Q6AFE_CLK(LPASS_CLK_ID_INTERNAL_DIGITAL_CODEC_CORE), + Q6AFE_CLK(LPASS_CLK_ID_INT_MCLK_0), + Q6AFE_CLK(LPASS_CLK_ID_INT_MCLK_1), + Q6AFE_CLK(LPASS_CLK_ID_WSA_CORE_MCLK), + Q6AFE_CLK(LPASS_CLK_ID_WSA_CORE_NPL_MCLK), + Q6AFE_CLK(LPASS_CLK_ID_VA_CORE_MCLK), + Q6AFE_CLK(LPASS_CLK_ID_TX_CORE_MCLK), + Q6AFE_CLK(LPASS_CLK_ID_TX_CORE_NPL_MCLK), + Q6AFE_CLK(LPASS_CLK_ID_RX_CORE_MCLK), + Q6AFE_CLK(LPASS_CLK_ID_RX_CORE_NPL_MCLK), + Q6AFE_CLK(LPASS_CLK_ID_VA_CORE_2X_MCLK), + + Q6AFE_VOTE_CLK(LPASS_HW_AVTIMER_VOTE, + Q6AFE_LPASS_CORE_AVTIMER_BLOCK, + "LPASS_AVTIMER_MACRO"), + Q6AFE_VOTE_CLK(LPASS_HW_MACRO_VOTE, + Q6AFE_LPASS_CORE_HW_MACRO_BLOCK, + "LPASS_HW_MACRO"), + Q6AFE_VOTE_CLK(LPASS_HW_DCODEC_VOTE, + Q6AFE_LPASS_CORE_HW_DCODEC_BLOCK, + "LPASS_HW_DCODEC"), }; static struct clk_hw *q6afe_of_clk_hw_get(struct of_phandle_args *clkspec,

1 0

License clarification of sound/soc/qcom/qdsp6/q6afe-clocks.c
by Lukas Bulwahn 26 Sep '20

26 Sep '20

Dear Srinivas, with commit 520a1c396d19 ("ASoC: q6afe-clocks: add q6afe clock controller"), you have added the file sound/soc/qcom/qdsp6/q6afe-clocks.c with the SPDX-License-Identifier: GPL-1.0. The use of 'GPL-1.0 only' is strongly not recommended as the Usage-Guide in ./LICENSES/deprecated/GPL-1.0 points out: The GNU General Public License (GPL) version 1 should not be used in new code. For existing kernel code the 'or any later version' option is required to be compatible with the general license of the project: GPLv2. At the end of the file, you further state it licensed with GPL-2.0 with the following line: MODULE_LICENSE("GPL v2"); So, is this just a typo in the SPDX-License-Identifier or do you really intend to license this file under GPL-1.0 only? Best regards, Lukas

2 1

a saner API for allocating DMA addressable pages v3
by Christoph Hellwig 26 Sep '20

26 Sep '20

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. As a follow up I plan to move the implementation of the DMA_ATTR_NO_KERNEL_MAPPING flag over to this framework as well, given that is also is a fundamentally non coherent allocation. The replacement for that flag would then return a struct page, as it is allowed to actually return pages without a kernel mapping as the name suggested (although most of the time they will actually have a kernel mapping..) In addition to the conversions of the existing non-coherent DMA users, I've also added a patch to convert the firewire ohci driver to use the new dma_alloc_pages API. The first patch is queued up for 5.9 in the media tree, but included here for completeness. A git tree is available here: git://git.infradead.org/users/hch/misc.git dma_alloc_pages Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma_alloc_p… Changes since v2: - fix up the patch reshuffle which wasn't quite correct - fix up a few commit messages Changes since v1: - rebased on the latests dma-mapping tree, which merged many of the cleanups - fix an argument passing typo in 53c700, caught by sparse - rename a few macro arguments in 53c700 - pass the right device to the DMA API in the lib82596 drivers - fix memory ownershiptransfers in sgiseeq - better document what a page in the direct kernel mapping means - split into dma_alloc_pages that returns a struct page and is in the direct mapping vs dma_alloc_noncoherent that can be vmapped - conver the firewire ohci driver to dma_alloc_pages Diffstat:

4 35

Ability to set ALSA PLUGIN DIR, etc. at runtime via environment variables
by GitHub issues - opened 26 Sep '20

26 Sep '20

alsa-project/alsa-lib issue #82 was opened from peanutbutterandcrackers: Hello there, I would like to request a feature to set things like `ALSA_PLUGIN_DIR` etc during runtime using environment variables. Currently, these seem to be set-able only at build-time, or by using a `.asoundrc` file. Or, if something like that is already possible, please do point me to the relevant documentation. Thank you very much. Issue URL : https://github.com/alsa-project/alsa-lib/issues/82 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

RE: [PATCH 3/3] [PATCH] staging: greybus: __u8 is sufficient for snd_ctl_elem_type_t and snd_ctl_elem_iface_t
by David Laight 26 Sep '20

26 Sep '20

From: Coiby Xu > Sent: 25 September 2020 15:11 > > On Thu, Sep 24, 2020 at 10:54:50AM +0000, David Laight wrote: > >From: Coiby Xu > >> Sent: 24 September 2020 11:21 > >> Use __8 to replace int and remove the unnecessary __bitwise type attribute. > >> > >> Found by sparse, > >... > >> diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h > >> index 535a7229e1d9..8e71a95644ab 100644 > >> --- a/include/uapi/sound/asound.h > >> +++ b/include/uapi/sound/asound.h > >> @@ -950,7 +950,7 @@ struct snd_ctl_card_info { > >> unsigned char components[128]; /* card components / fine identification, delimited with one > >> space (AC97 etc..) */ > >> }; > >> > >> -typedef int __bitwise snd_ctl_elem_type_t; > >> +typedef __u8 snd_ctl_elem_type_t; > >> #define SNDRV_CTL_ELEM_TYPE_NONE ((__force snd_ctl_elem_type_t) 0) /* invalid */ > >> #define SNDRV_CTL_ELEM_TYPE_BOOLEAN ((__force snd_ctl_elem_type_t) 1) /* boolean type */ > >> #define SNDRV_CTL_ELEM_TYPE_INTEGER ((__force snd_ctl_elem_type_t) 2) /* integer type */ > > > >WTF is all that about anyway?? > >What is wrong with: > >#define SNDRV_CTL_ELEM_TYPE_NONE 0u /* invalid */ > > I'm sorry I don't quite understand you. Are you suggesting SNDRV_CTL_ELEM_TYPE_NONE > isn't needed in the first place? No, just remove all the casts from the constants. Are the types even used anywhere else? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)

1 0

[PATCH v8 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point
by Cezary Rojewski 26 Sep '20

26 Sep '20

Implement support for Lynxpoint and Wildcat Point AudioDSP. Catpt solution deprecates existing sound/soc/intel/haswell which is removed in the following series. Due to high range of errors and desynchronization from recommendations set by Windows solution, re-write came as a lower-cost solution compared to refactoring /haswell/ with several series of patches. Series is dependent on linux-spi change: spi: pxa2xx: Add SSC2 and SSPSP2 SSP registers https://www.spinics.net/lists/linux-spi/msg23885.html which has been already merged and is now part of linux-spi tree. Bulk of series content is device driver core code - everything up to patch 7/14 - with fs entries and trace macros introduced right after. While each core patch is shaped in such a way that no unavailable members are ever called, until patch 14/14 is applied, no code compilation can occur as no Makefile is present. Once said patch is added, Makefile and Kconfig are implemented and driver module compiles as expected. Special thanks go to Marcin Barlik and Piotr Papierkowski for sharing their LPT/WPT AudioDSP architecture expertise as well as helping backtrack its historical background. My thanks go to Amadeusz Slawinski for reviews and improvements proposed on and off the internal list. Most of internal diff below is his contribution. Krzysztof Hejmowski helped me setup my own Xtensa environment and recompile LPT/WPT FW binary sources what sped up the development greatly. This would not have been possible without help from these champions, especially considering how quickly the catpt was written: 2 weeks features, 3 weeks optimizations. Thank you. Userspace-exposed members are compatible with what is exposed by deprecated solution as well as FW binary being re-used thus no harm is done. The only visible differences are: the newly added 'Loopback Mute' kcontrol and volume support extending to quad from stereo. On top of fixing erros and design flows, catpt also adds module reload, dynamic SRAM memory allocation during PCM runtime and exposes missing userspace API: 'Loopback Mute' kcontrol, quad volume controls and sysfs fw-version entries. Event tracing is provided to easy solution debugging. Following are not included in this update and are scheduled as later addition: - fw logging - module (library) support Note: LPT power up/down sequences might get aligned with WPT once enough testing is done as capabilities are shared for both DSPs. Note #2: Both LPT and WPT power up/down sequences may get optimized in future updates as thanks to help from the Windows team, most of nuances behind why/what/when in regard to hw registers have been backtracked and reviewed again. Link to developer's deep dive message: https://www.spinics.net/lists/alsa-devel/msg113563.html Changes in v8: - updated catpt_arrange_page_table() with GENMASK and U32_MAX usage - made use of PFN_DOWN() replacing explicit right shitfs by PAGE_SIZE - made fw hash dumping in catpt_coredump() more readable and removed hardcodes - catpt_coredump() dumps fw hash now only if said segment has been found within fw_info - shortened _MSECS suffixes to _MS - IPC structs no longer contain enum members - simplified definition of catpt_set_dspvol() Changes in v7: https://www.spinics.net/lists/alsa-devel/msg116019.html - fixed licence header for fs.c - renamed fs.c to sysfs.c to better match its purpose - added documentation within Documentation/ABI/testing for entries exposed by catpt - bin_attribute fw_build replaced by attribute fw_info: fw_info contains full FW information and after successful handshake, it's always available (stored in driver data) so no need to invoke GET_FW_VERSION IPC again, just dump the stored information - rather than manually creating and removing sysfs files, now makes use of dev_groups member of struct device_driver - patch: 10/14 'ASoC: Intel: Select catpt and deprecate haswell' has been moved to the back of the list: enable catpt after machine boards have been prepared for it first - improved readability of several goto labels Changes in v6: https://www.spinics.net/lists/alsa-devel/msg115765.html - reordered and reorganized code for patches 1/13 - 8/13 of v5, so each patches makes use of no member or function which is unavailable to it. Series size increased from 13 to 14 patches: addition of base members e.g.: registers has been split from addition of device.c file which describes acpi device behavior Changes in v5: https://www.spinics.net/lists/alsa-devel/msg115621.html Basically everything below is result of Andy's review. Thank you Andy for taking time into this detailed review - catpt now makes use of common linux/pxa2xx_ssp.h header file, removing redundant SSP register declarations in the process. As stated in the opening, this is dependent upon linux-spi change: spi: pxa2xx: Add SSC2 and SSPSP2 SSP registers - updated Kconfig by removing DMADEVICES and adding COMPILE_TEST as optional depends-on - updated all register macros definitions to be more safe against common arithmetics when specifying macro's parameters - removed CONFIG_PM and CONFIG_PM_SLEEP usage in favor of __maybe_unused - all 'if (ret < 0)' converted to simple 'if (ret)' whenever possible - fixed erroneous check for platform_device_register_data within catpt_register_board() - _SLAVE/_MASTER replaced with more inclusive _CONSUMER/_PROVIDER for enum catpt_ssp_mode - catpt_acpi_probe() is now making use of high-level wrappers for ioremapping and resource assignment, reducing function's code size - due to improved catpt_acpi_probe() behavior, catpt_acpi_remove() needs not to cast dma_free_coherent() any longer - DMA source and destrination maxburst now of value 16, see: https://www.spinics.net/lists/alsa-devel/msg114394.html - simplified catpt_dsp_update_lpclock() as list_for_each_entry() is empty-safe by default - dropped '_SSP_' from all names of all CATPT_SSP_SSXXX_DEFAULT macros - catpt_updatel_pci now makes use of linux/pci.h and uapi/linux/pci.h constants such as: PCI_PM_CTRL_STATE_MASK and PCI_D3hot Changes in v4: https://www.spinics.net/lists/alsa-devel/msg113762.html - fixed compilation with i386 kconfig (conflicting names) - streamlined naming for SHIM and PCI registers to match SSP ones (SHIM_REG -> SHIM) - catpt_component_probe removed and kcontrols again initializzed statically via snd_kcontrol_new array: this is to remove kctl->id.device shenanigans - renamed catpt_set_ctlvol to catpt_set_dspvol - function name wasn't matching its purpose Changes in v3: - fixed IRAM mask usage in lpt_dsp_power_up (dsp.c) - updated dbg message formatting in catpt_restore_fwimage as suggested by Andy - fixed alignment for struct catpt_ssp_device_format - catpt_set_ctlvol now verifies all-equal scenario based on all channels rather than just first two as requested by Amadeo - fixed SPDX for registers.h Changes in v2: https://www.spinics.net/lists/alsa-devel/msg113660.html - fixed SPDX formatting for all header files as well as pcm.c - fixed size provided to memcpy() in fw_build_read() as reported by Mark - renamed struct catpt_pdata to struct catpt_spec (cosmetic) - fixed erroneous path in catpt_load_block: region is properly released - trace.h events for updating registers have been removed and usages replaced by dev_dbg (SRAMPGE/ LPCS) - as requested by Andy, struct resource has replaced struct catpt_mbank and struct catpt_mregion. This change cascaded into: - catpt_mbank_size and catpt_mregion_size replaced by resource_size - catpt_mregion_intersects replaced by resource_overlaps - all catpt_mbank_ and catpt_mregion_ handlers found in loader.c (_request, _reserve, _release, _extract, _split, _join) have been removed - __request_region and __release_region have been enlisted in their place - catpt_mregion_intersecting renamed to catpt_resource_overlapping - catpt_request_region helper has been provided to deal with -size based requests o haven't found direct replacements in resource.c/ ioport.h for both functions - catpt_mbank_create and catpt_mbank_remove renamed to catpt_sram_init and catpt_sram_free respectively - catpt_sram_init now returns void instead of int and has been converted to simple initialized. This change ultimately cascaded into: o both SRAM banks initialization being moved to catpt_dev_init from catpt_acpi_probe (device.c) o catpt_dev::spec is now initialized first, with catpt_dev_init following it soon after o catpt_acpi_probe erroneous path has been simplified as SRAM banks no longer need to be freed - catpt_sram_free now frees all resources via child -> sibling enumeration rather than region_list iteration - catpt_dsp_update_srampge and catpt_dsp_set_srampge now accept new argument: unsigned long mask. Caused by removal of catpt_mbank - mask is taken directly from catpt_dev::spec::d/iram_mask - trace.h events for catpt_mbank and catpt_mregion have been removed Diff against last drop on internal list: https://www.spinics.net/lists/alsa-devel/msg113549.html - replaced spinlock with mutex for mregion allocation and release to address sleeping in atomic context warnings - fixed coredump fw_hash dumping - kcontrol values are now always stored regardless of stream of interest is running or not - kcontrol values are now applied after stream is prepared instead of ignoring what has been set by user initially - catpt_pdata instances have been renamed from hsw_ and bdw_ to lpt_ and wpt_ respectively - reordered Makefile .o(s) (cosmetic) Cezary Rojewski (14): ASoC: Intel: Add catpt base members ASoC: Intel: catpt: Implement IPC protocol ASoC: Intel: catpt: Add IPC message handlers ASoC: Intel: catpt: Define DSP operations ASoC: Intel: catpt: Firmware loading and context restore ASoC: Intel: catpt: PCM operations ASoC: Intel: catpt: Device driver lifecycle ASoC: Intel: catpt: Event tracing ASoC: Intel: catpt: Simple sysfs attributes ASoC: Intel: haswell: Remove haswell-solution specific code ASoC: Intel: broadwell: Remove haswell-solution specific code ASoC: Intel: bdw-5650: Remove haswell-solution specific code ASoC: Intel: bdw-5677: Remove haswell-solution specific code ASoC: Intel: Select catpt and deprecate haswell .../ABI/testing/sysfs-bus-pci-devices-catpt | 16 + sound/soc/intel/Kconfig | 24 +- sound/soc/intel/Makefile | 2 +- sound/soc/intel/boards/Kconfig | 8 +- sound/soc/intel/boards/bdw-rt5650.c | 36 - sound/soc/intel/boards/bdw-rt5677.c | 33 - sound/soc/intel/boards/broadwell.c | 33 - sound/soc/intel/boards/haswell.c | 28 +- sound/soc/intel/catpt/Makefile | 6 + sound/soc/intel/catpt/core.h | 187 +++ sound/soc/intel/catpt/device.c | 348 +++++ sound/soc/intel/catpt/dsp.c | 578 ++++++++ sound/soc/intel/catpt/ipc.c | 298 ++++ sound/soc/intel/catpt/loader.c | 671 +++++++++ sound/soc/intel/catpt/messages.c | 313 +++++ sound/soc/intel/catpt/messages.h | 401 ++++++ sound/soc/intel/catpt/pcm.c | 1211 +++++++++++++++++ sound/soc/intel/catpt/registers.h | 178 +++ sound/soc/intel/catpt/sysfs.c | 57 + sound/soc/intel/catpt/trace.h | 83 ++ 20 files changed, 4368 insertions(+), 143 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-catpt create mode 100644 sound/soc/intel/catpt/Makefile create mode 100644 sound/soc/intel/catpt/core.h create mode 100644 sound/soc/intel/catpt/device.c create mode 100644 sound/soc/intel/catpt/dsp.c create mode 100644 sound/soc/intel/catpt/ipc.c create mode 100644 sound/soc/intel/catpt/loader.c create mode 100644 sound/soc/intel/catpt/messages.c create mode 100644 sound/soc/intel/catpt/messages.h create mode 100644 sound/soc/intel/catpt/pcm.c create mode 100644 sound/soc/intel/catpt/registers.h create mode 100644 sound/soc/intel/catpt/sysfs.c create mode 100644 sound/soc/intel/catpt/trace.h -- 2.17.1

5 32

[PATCH] fsl: imx-audmix : Use devm_kcalloc() instead of devm_kzalloc()
by Xu Wang 25 Sep '20

25 Sep '20

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "devm_kcalloc". Signed-off-by: Xu Wang <vulab(a)iscas.ac.cn> --- sound/soc/fsl/imx-audmix.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c index 202fb8950078..cbdc0a2c09c5 100644 --- a/sound/soc/fsl/imx-audmix.c +++ b/sound/soc/fsl/imx-audmix.c @@ -185,20 +185,20 @@ static int imx_audmix_probe(struct platform_device *pdev) return -ENOMEM; priv->num_dai = 2 * num_dai; - priv->dai = devm_kzalloc(&pdev->dev, priv->num_dai * + priv->dai = devm_kcalloc(&pdev->dev, priv->num_dai, sizeof(struct snd_soc_dai_link), GFP_KERNEL); if (!priv->dai) return -ENOMEM; priv->num_dai_conf = num_dai; - priv->dai_conf = devm_kzalloc(&pdev->dev, priv->num_dai_conf * + priv->dai_conf = devm_kcalloc(&pdev->dev, priv->num_dai_conf, sizeof(struct snd_soc_codec_conf), GFP_KERNEL); if (!priv->dai_conf) return -ENOMEM; priv->num_dapm_routes = 3 * num_dai; - priv->dapm_routes = devm_kzalloc(&pdev->dev, priv->num_dapm_routes * + priv->dapm_routes = devm_kcalloc(&pdev->dev, priv->num_dapm_routes, sizeof(struct snd_soc_dapm_route), GFP_KERNEL); if (!priv->dapm_routes) @@ -208,7 +208,7 @@ static int imx_audmix_probe(struct platform_device *pdev) struct snd_soc_dai_link_component *dlc; /* for CPU/Codec/Platform x 2 */ - dlc = devm_kzalloc(&pdev->dev, 6 * sizeof(*dlc), GFP_KERNEL); + dlc = devm_kcalloc(&pdev->dev, 6, sizeof(*dlc), GFP_KERNEL); if (!dlc) { dev_err(&pdev->dev, "failed to allocate dai_link\n"); return -ENOMEM; -- 2.17.1

2 1

[PATCH 0/2] ASoC: qdsp6: fix some warnings when build without CONFIG_OF
by Srinivas Kandagatla 25 Sep '20

25 Sep '20

Here are fixes for two warnings types discovered while building qdsp6 drivers without CONFIG_OF and with W=1 One of them was reported by Intel kernel test robot on q6afe-clocks patch, which equally applies to rest of the qdsp6 drivers. Srinivas Kandagatla (2): ASoC: qdsp6: Drop of_match_ptr to fix -Wunused-const-variable ASoC: q6asm: fix kernel doc warnings sound/soc/qcom/qdsp6/q6adm.c | 2 +- sound/soc/qcom/qdsp6/q6afe-clocks.c | 2 +- sound/soc/qcom/qdsp6/q6afe-dai.c | 2 +- sound/soc/qcom/qdsp6/q6afe.c | 2 +- sound/soc/qcom/qdsp6/q6asm-dai.c | 2 +- sound/soc/qcom/qdsp6/q6asm.c | 5 ++++- sound/soc/qcom/qdsp6/q6core.c | 2 +- sound/soc/qcom/qdsp6/q6routing.c | 2 +- 8 files changed, 11 insertions(+), 8 deletions(-) -- 2.21.0

2 5

[PATCH 1/2] ASoC: cs47l15: Fix EPOUT->HPOUT1 Mono Mux routing
by Richard Fitzgerald 25 Sep '20

25 Sep '20

EPOUT is always mono so should have a permanent routing through the HPOUT1 Mono Mux. Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> --- sound/soc/codecs/cs47l15.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/cs47l15.c b/sound/soc/codecs/cs47l15.c index a591e7457d11..254f9d96e766 100644 --- a/sound/soc/codecs/cs47l15.c +++ b/sound/soc/codecs/cs47l15.c @@ -1089,6 +1089,7 @@ static const struct snd_soc_dapm_route cs47l15_dapm_routes[] = { { "HPOUT1 Demux", NULL, "OUT1R" }, { "OUT1R", NULL, "HPOUT1 Mono Mux" }, + { "HPOUT1 Mono Mux", "EPOUT", "OUT1L" }, { "HPOUTL", "HPOUT", "HPOUT1 Demux" }, { "HPOUTR", "HPOUT", "HPOUT1 Demux" }, @@ -1268,7 +1269,6 @@ static irqreturn_t cs47l15_adsp2_irq(int irq, void *data) static const struct snd_soc_dapm_route cs47l15_mono_routes[] = { { "HPOUT1 Mono Mux", "HPOUT", "OUT1L" }, - { "HPOUT1 Mono Mux", "EPOUT", "OUT1L" }, }; static int cs47l15_component_probe(struct snd_soc_component *component) -- 2.20.1

2 2

[PATCH] Asoc: qcom: lpass-cpu: Enable MI2S BCLK and LRCLK together
by Srinivasa Rao Mandadapu 25 Sep '20

25 Sep '20

From: vsujithk <vsujithk(a)codeaurora.org> Update lpass-cpu.c to enable I2S BCLK and LRCLK together. Remove BCLK enable in lpass_cpu_daiops_startup and add in lpass_cpu_daiops_trigger API. Signed-off-by: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Signed-off-by: Srinivasa Rao Mandadapu <srivasam(a)codeaurora.org> --- sound/soc/qcom/lpass-cpu.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c index 41a2470..8db2cdb 100644 --- a/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-cpu.c @@ -80,14 +80,6 @@ static int lpass_cpu_daiops_startup(struct snd_pcm_substream *substream, dev_err(dai->dev, "error in enabling mi2s osr clk: %d\n", ret); return ret; } - - ret = clk_prepare_enable(drvdata->mi2s_bit_clk[dai->driver->id]); - if (ret) { - dev_err(dai->dev, "error in enabling mi2s bit clk: %d\n", ret); - clk_disable_unprepare(drvdata->mi2s_osr_clk[dai->driver->id]); - return ret; - } - return 0; } @@ -310,6 +302,14 @@ static int lpass_cpu_daiops_trigger(struct snd_pcm_substream *substream, if (ret) dev_err(dai->dev, "error writing to i2sctl reg: %d\n", ret); + + ret = clk_prepare_enable(drvdata->mi2s_bit_clk[id]); + if (ret) { + dev_err(dai->dev, "error in enabling mi2s bit clk: %d\n", ret); + clk_disable_unprepare(drvdata->mi2s_osr_clk[id]); + return ret; + } + break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

2 1

[PATCH v2 0/2] ASoC: qdsp6: fix some warnings when build without CONFIG_OF
by Srinivas Kandagatla 25 Sep '20

25 Sep '20

Here are fixes for two warnings types discovered while building qdsp6 drivers without CONFIG_OF and with W=1 One of them was reported by Intel kernel test robot on q6afe-clocks patch, which equally applies to rest of the qdsp6 drivers. changes since v1: - added ifdef CONFIG_OF instead of removing of_match_ptr Srinivas Kandagatla (2): ASoC: qdsp6: add ifdef CONFIG_OF around of_device_id ASoC: q6asm: fix kernel doc warnings sound/soc/qcom/qdsp6/q6adm.c | 2 ++ sound/soc/qcom/qdsp6/q6afe-clocks.c | 2 ++ sound/soc/qcom/qdsp6/q6afe-dai.c | 2 ++ sound/soc/qcom/qdsp6/q6afe.c | 2 ++ sound/soc/qcom/qdsp6/q6asm-dai.c | 2 ++ sound/soc/qcom/qdsp6/q6asm.c | 6 ++++++ sound/soc/qcom/qdsp6/q6core.c | 2 ++ sound/soc/qcom/qdsp6/q6routing.c | 2 ++ 8 files changed, 20 insertions(+) -- 2.21.0

2 3

[PATCH] dt-bindings: tas2770: Mark ti,asi-format to deprecated
by Dan Murphy 25 Sep '20

25 Sep '20

Mark the property ti,asi-format to deprecated as it is no longer supported. Signed-off-by: Dan Murphy <dmurphy(a)ti.com> --- Documentation/devicetree/bindings/sound/tas2770.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/tas2770.yaml b/Documentation/devicetree/bindings/sound/tas2770.yaml index 9fdf614add55..07e7f9951d2e 100644 --- a/Documentation/devicetree/bindings/sound/tas2770.yaml +++ b/Documentation/devicetree/bindings/sound/tas2770.yaml @@ -44,6 +44,7 @@ properties: description: TDM TX voltage sense time slot. ti,asi-format: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 description: Sets TDM RX capture edge. enum: -- 2.28.0

2 1

[PATCH] ASoC: fsl_sai: Instantiate snd_soc_dai_driver
by Shengjiu Wang 25 Sep '20

25 Sep '20

Instantiate snd_soc_dai_driver for independent symmetric control. Otherwise the symmetric setting may be overwritten by other instance. Fixes: 08fdf65e37d5 ("ASoC: fsl_sai: Add asynchronous mode support") Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- sound/soc/fsl/fsl_sai.c | 19 +++++++++++-------- sound/soc/fsl/fsl_sai.h | 1 + 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index 5117c1cd5682..3e5c1eaccd5e 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -725,7 +725,7 @@ static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai) return 0; } -static struct snd_soc_dai_driver fsl_sai_dai = { +static struct snd_soc_dai_driver fsl_sai_dai_template = { .probe = fsl_sai_dai_probe, .playback = { .stream_name = "CPU-Playback", @@ -1062,12 +1062,15 @@ static int fsl_sai_probe(struct platform_device *pdev) return ret; } + memcpy(&sai->cpu_dai_drv, &fsl_sai_dai_template, + sizeof(fsl_sai_dai_template)); + /* Sync Tx with Rx as default by following old DT binding */ sai->synchronous[RX] = true; sai->synchronous[TX] = false; - fsl_sai_dai.symmetric_rates = 1; - fsl_sai_dai.symmetric_channels = 1; - fsl_sai_dai.symmetric_samplebits = 1; + sai->cpu_dai_drv.symmetric_rates = 1; + sai->cpu_dai_drv.symmetric_channels = 1; + sai->cpu_dai_drv.symmetric_samplebits = 1; if (of_find_property(np, "fsl,sai-synchronous-rx", NULL) && of_find_property(np, "fsl,sai-asynchronous", NULL)) { @@ -1084,9 +1087,9 @@ static int fsl_sai_probe(struct platform_device *pdev) /* Discard all settings for asynchronous mode */ sai->synchronous[RX] = false; sai->synchronous[TX] = false; - fsl_sai_dai.symmetric_rates = 0; - fsl_sai_dai.symmetric_channels = 0; - fsl_sai_dai.symmetric_samplebits = 0; + sai->cpu_dai_drv.symmetric_rates = 0; + sai->cpu_dai_drv.symmetric_channels = 0; + sai->cpu_dai_drv.symmetric_samplebits = 0; } if (of_find_property(np, "fsl,sai-mclk-direction-output", NULL) && @@ -1128,7 +1131,7 @@ static int fsl_sai_probe(struct platform_device *pdev) regcache_cache_only(sai->regmap, true); ret = devm_snd_soc_register_component(&pdev->dev, &fsl_component, - &fsl_sai_dai, 1); + &sai->cpu_dai_drv, 1); if (ret) goto err_pm_disable; diff --git a/sound/soc/fsl/fsl_sai.h b/sound/soc/fsl/fsl_sai.h index ba7425a9e217..4bbcd0dbe8f1 100644 --- a/sound/soc/fsl/fsl_sai.h +++ b/sound/soc/fsl/fsl_sai.h @@ -267,6 +267,7 @@ struct fsl_sai { unsigned int bclk_ratio; const struct fsl_sai_soc_data *soc_data; + struct snd_soc_dai_driver cpu_dai_drv; struct snd_dmaengine_dai_dma_data dma_params_rx; struct snd_dmaengine_dai_dma_data dma_params_tx; struct fsl_sai_verid verid; -- 2.27.0

2 1

[PATCH 1/3] ASoC: cs4234: Add dtschema binding document
by Richard Fitzgerald 25 Sep '20

25 Sep '20

From: Charles Keepax <ckeepax(a)opensource.cirrus.com> Document the bindings for the CS4234 ASoC codec driver. Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> --- .../bindings/sound/cirrus,cs4234.yaml | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/cirrus,cs4234.yaml diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs4234.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs4234.yaml new file mode 100644 index 000000000000..156560b2a980 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cirrus,cs4234.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/cirrus,cs4234.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic cs4234 audio CODEC + +maintainers: + - patches(a)opensource.cirrus.com + +description: + The CS4234 is a highly versatile CODEC that combines 4 channels of + high performance analog to digital conversion, 4 channels of high + performance digital to analog conversion for audio, and 1 channel of + digital to analog conversion to provide a nondelayed audio reference + signal to an external Class H tracking power supply. If not used to + drive a tracking power supply, the 5th DAC can instead be used as a + standard audio grade DAC, with performance specifications identical + to that of the 4 DACs in the audio path. Additionally, the CS4234 + includes tunable group delay for each of the 4 audio DAC paths to + provide lead time for the external switch-mode power supply, and a + nondelayed path into the DAC outputs for input signals requiring a + low-latency path to the outputs. + +properties: + compatible: + enum: + - cirrus,cs4234 + + reg: + description: + The 7-bit I2C address depends on the state of the ADx pins, in + binary given by [0 0 1 0 AD2 AD1 AD0 0]. + items: + minimum: 0x10 + maximum: 0x17 + + VA-supply: + description: + Analogue power supply. + + VL-supply: + description: + Interface power supply. + + reset-gpios: + maxItems: 1 + +required: + - compatible + - reg + - VA-supply + - VL-supply + +additionalProperties: false + +examples: + - | + i2c@e0004000 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe0004000 0x1000>; + + cs4234: codec@11 { + compatible = "cirrus,cs4234"; + reg = <0x11>; + + VA-supply = <&vdd3v3>; + VL-supply = <&vdd3v3>; + + reset-gpios = <&gpio 0>; + }; + }; -- 2.20.1

2 4

[PATCH 0/2] Enable runtime PM for SOF device
by Daniel Baluta 25 Sep '20

25 Sep '20

From: Daniel Baluta <daniel.baluta(a)nxp.com> This enables runtime PM for SOF device. Next patchseries will provide PM suspend/resume handlers for i.MX8 specific devices. Daniel Baluta (2): ASoC: SOF: Activate runtime PM with SOF OF device ASoC: SOF: Add .prepare/.complete callbacks sound/soc/sof/sof-of-dev.c | 6 ++++++ 1 file changed, 6 insertions(+) -- 2.17.1

2 3

[PATCH] fsl: imx-audmix : Replace seq_printf with seq_puts
by Xu Wang 25 Sep '20

25 Sep '20

A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "devm_kcalloc". Signed-off-by: Xu Wang <vulab(a)iscas.ac.cn> --- sound/soc/fsl/imx-audmix.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c index 202fb8950078..cbdc0a2c09c5 100644 --- a/sound/soc/fsl/imx-audmix.c +++ b/sound/soc/fsl/imx-audmix.c @@ -185,20 +185,20 @@ static int imx_audmix_probe(struct platform_device *pdev) return -ENOMEM; priv->num_dai = 2 * num_dai; - priv->dai = devm_kzalloc(&pdev->dev, priv->num_dai * + priv->dai = devm_kcalloc(&pdev->dev, priv->num_dai, sizeof(struct snd_soc_dai_link), GFP_KERNEL); if (!priv->dai) return -ENOMEM; priv->num_dai_conf = num_dai; - priv->dai_conf = devm_kzalloc(&pdev->dev, priv->num_dai_conf * + priv->dai_conf = devm_kcalloc(&pdev->dev, priv->num_dai_conf, sizeof(struct snd_soc_codec_conf), GFP_KERNEL); if (!priv->dai_conf) return -ENOMEM; priv->num_dapm_routes = 3 * num_dai; - priv->dapm_routes = devm_kzalloc(&pdev->dev, priv->num_dapm_routes * + priv->dapm_routes = devm_kcalloc(&pdev->dev, priv->num_dapm_routes, sizeof(struct snd_soc_dapm_route), GFP_KERNEL); if (!priv->dapm_routes) @@ -208,7 +208,7 @@ static int imx_audmix_probe(struct platform_device *pdev) struct snd_soc_dai_link_component *dlc; /* for CPU/Codec/Platform x 2 */ - dlc = devm_kzalloc(&pdev->dev, 6 * sizeof(*dlc), GFP_KERNEL); + dlc = devm_kcalloc(&pdev->dev, 6, sizeof(*dlc), GFP_KERNEL); if (!dlc) { dev_err(&pdev->dev, "failed to allocate dai_link\n"); return -ENOMEM; -- 2.17.1

2 2

[PATCH] ALSA: rockchip: fix a possible divide-by-zero bug in rockchip_i2s_hw_params()
by Tuo Li 25 Sep '20

25 Sep '20

The variable bclk_rate is checked in: if (bclk_rate && mclk_rate % bclk_rate) This indicates that bclk_rate can be zero. If so, a divide-by-zero bug will occur: div_bclk = mclk_rate / bclk_rate; To fix this possible bug, the function returns -EINVAL when bclk_rate is zero. Signed-off-by: Tuo Li <t-li20(a)mails.tsinghua.edu.cn> --- sound/soc/rockchip/rockchip_i2s.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c index d1438753edb4..dd0836c32639 100644 --- a/sound/soc/rockchip/rockchip_i2s.c +++ b/sound/soc/rockchip/rockchip_i2s.c @@ -279,7 +279,9 @@ static int rockchip_i2s_hw_params(struct snd_pcm_substream *substream, if (i2s->is_master_mode) { mclk_rate = clk_get_rate(i2s->mclk); bclk_rate = 2 * 32 * params_rate(params); - if (bclk_rate && mclk_rate % bclk_rate) + if (bclk_rate == 0) + return -EINVAL; + if (mclk_rate % bclk_rate) return -EINVAL; div_bclk = mclk_rate / bclk_rate; -- 2.17.1

2 2

Re: [greybus-dev] [PATCH 3/3] [PATCH] staging: greybus: __u8 is sufficient for snd_ctl_elem_type_t and snd_ctl_elem_iface_t
by Alex Elder 25 Sep '20

25 Sep '20

On 9/25/20 9:11 AM, Coiby Xu wrote: > On Thu, Sep 24, 2020 at 10:54:50AM +0000, David Laight wrote: >> From: Coiby Xu >>> Sent: 24 September 2020 11:21 >>> Use __8 to replace int and remove the unnecessary __bitwise type >>> attribute. >>> >>> Found by sparse, >> ... >>> diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h >>> index 535a7229e1d9..8e71a95644ab 100644 >>> --- a/include/uapi/sound/asound.h >>> +++ b/include/uapi/sound/asound.h >>> @@ -950,7 +950,7 @@ struct snd_ctl_card_info { >>> unsigned char components[128]; /* card components / fine >>> identification, delimited with one >>> space (AC97 etc..) */ >>> }; >>> >>> -typedef int __bitwise snd_ctl_elem_type_t; >>> +typedef __u8 snd_ctl_elem_type_t; >>> #define SNDRV_CTL_ELEM_TYPE_NONE ((__force >>> snd_ctl_elem_type_t) 0) /* invalid */ >>> #define SNDRV_CTL_ELEM_TYPE_BOOLEAN ((__force >>> snd_ctl_elem_type_t) 1) /* boolean type */ >>> #define SNDRV_CTL_ELEM_TYPE_INTEGER ((__force >>> snd_ctl_elem_type_t) 2) /* integer type */ >> >> WTF is all that about anyway?? >> What is wrong with: >> #define SNDRV_CTL_ELEM_TYPE_NONE 0u /* invalid */ > > I'm sorry I don't quite understand you. Are you suggesting > SNDRV_CTL_ELEM_TYPE_NONE > isn't needed in the first place? I think David is asking why it's defined the way it is, and I'd guess it's to have the compiler issue an error if you attempt to assign one of these values to a variable or field of the wrong type. No, you should not attempt to change this. -Alex >> David >> >> - >> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, >> MK1 1PT, UK >> Registration No: 1397386 (Wales) >> > > -- > Best regards, > Coiby > _______________________________________________ > greybus-dev mailing list > greybus-dev(a)lists.linaro.org > https://lists.linaro.org/mailman/listinfo/greybus-dev

1 0

Re: [PATCH 3/3] [PATCH] staging: greybus: __u8 is sufficient for snd_ctl_elem_type_t and snd_ctl_elem_iface_t
by Alex Elder 25 Sep '20

25 Sep '20

On 9/25/20 9:07 AM, Coiby Xu wrote: > On Thu, Sep 24, 2020 at 01:00:57PM +0200, Greg Kroah-Hartman wrote: >> On Thu, Sep 24, 2020 at 06:20:39PM +0800, Coiby Xu wrote: >>> Use __8 to replace int and remove the unnecessary __bitwise type >>> attribute. >>> >>> Found by sparse, . . . >>> diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h >>> index 535a7229e1d9..8e71a95644ab 100644 >>> --- a/include/uapi/sound/asound.h >>> +++ b/include/uapi/sound/asound.h >>> @@ -950,7 +950,7 @@ struct snd_ctl_card_info { >>> unsigned char components[128]; /* card components / fine >>> identification, delimited with one space (AC97 etc..) */ >>> }; >>> >>> -typedef int __bitwise snd_ctl_elem_type_t; >>> +typedef __u8 snd_ctl_elem_type_t; >>> #define SNDRV_CTL_ELEM_TYPE_NONE ((__force >>> snd_ctl_elem_type_t) 0) /* invalid */ >>> #define SNDRV_CTL_ELEM_TYPE_BOOLEAN ((__force >>> snd_ctl_elem_type_t) 1) /* boolean type */ >>> #define SNDRV_CTL_ELEM_TYPE_INTEGER ((__force >>> snd_ctl_elem_type_t) 2) /* integer type */ >>> @@ -960,7 +960,7 @@ typedef int __bitwise snd_ctl_elem_type_t; >>> #define SNDRV_CTL_ELEM_TYPE_INTEGER64 ((__force >>> snd_ctl_elem_type_t) 6) /* 64-bit integer type */ >>> #define SNDRV_CTL_ELEM_TYPE_LAST SNDRV_CTL_ELEM_TYPE_INTEGER64 >>> >>> -typedef int __bitwise snd_ctl_elem_iface_t; >>> +typedef __u8 snd_ctl_elem_iface_t; >>> #define SNDRV_CTL_ELEM_IFACE_CARD ((__force >>> snd_ctl_elem_iface_t) 0) /* global control */ >>> #define SNDRV_CTL_ELEM_IFACE_HWDEP ((__force >>> snd_ctl_elem_iface_t) 1) /* hardware dependent device */ >>> #define SNDRV_CTL_ELEM_IFACE_MIXER ((__force >>> snd_ctl_elem_iface_t) 2) /* virtual mixer device */ >> >> I can't take a uapi sound header file patch along with a driver change, >> these need to be independant. > > Thank you and Alex for reminding me this is a change of public header! >> >> And this is a userspace api, you just changed the size of an externally >> facing variable, are you _SURE_ that is ok to do? > > The reasons I make this change are, 1) using int to represent 7 enumeration > values seems to be overkill; 2) using one type could avoid worries > about byte order. (1) might be a valid suggestion, but the file you suggest changing is part of the Linux user space API, which you basically can't change. I'm fairly certain the user space API is defined to have CPU-local byte order (unless specified explicitly otherwise) so that is not a concern. > I examine one userspace example (libalsa-intf/alsa_mixer.c [1]). This > change won't cause compiling breakage. But I don't the experience to > imagine any other bad consequence. As a rule, once the user space API has been established, it stays with us forever. You can add to it, but modifying (or removing) an existing interface is essentially forbidden. > Another way to avoid userspace API change is to let > "struct gb_audio_ctl_elem_info" use snd_ctl_elem_iface_t type which may > be more elegant than using "__force" as suggested by Alex, The Greybus definitions were explicitly defined to be operating system independent. For that reason there are (admittedly cumbersome) definitions of certain types and values that essentially mimic those defined by Linux exactly That way Linux (or another system using Greybus) can change its internal values without changing the Greybus API definition. (This addresses the concern you mention below.) What you are suggesting is not consistent with that principle. -Alex > $ git diff > diff --git a/include/linux/greybus/greybus_protocols.h > b/include/linux/greybus/greybus_protocols.h > index aeb8f9243545..7f6753ec7ef7 100644 > --- a/include/linux/greybus/greybus_protocols.h > +++ b/include/linux/greybus/greybus_protocols.h > @@ -8,6 +8,7 @@ > #define __GREYBUS_PROTOCOLS_H > > #include <linux/types.h> > +#include <sound/asound.h> > > /* Fixed IDs for control/svc protocols */ > > @@ -1997,7 +1998,7 @@ struct gb_audio_enumerated { > } __packed; > > struct gb_audio_ctl_elem_info { /* See snd_ctl_elem_info in Linux > source */ > - __u8 type; /* GB_AUDIO_CTL_ELEM_TYPE_* */ > + snd_ctl_elem_type_t type; /* > GB_AUDIO_CTL_ELEM_TYPE_* */ > __le16 dimen[4]; > union { > struct gb_audio_integer integer > > My only concern is if greybus authors have any special reason to not > include > sound/asound.h in the first place and re-define things like > SNDRV_CTL_ELEM_TYPE_*, > > /* See SNDRV_CTL_ELEM_TYPE_* in Linux source */ > #define GB_AUDIO_CTL_ELEM_TYPE_BOOLEAN 0x01 > #define GB_AUDIO_CTL_ELEM_TYPE_INTEGER 0x02 > > /* See SNDRV_CTL_ELEM_IFACE_* in Linux source */ > #define GB_AUDIO_CTL_ELEM_IFACE_CARD 0x00 > ... > > /* SNDRV_CTL_ELEM_ACCESS_* in Linux source */ > #define GB_AUDIO_ACCESS_READ BIT(0) > ... > > [1] > https://gitlab.com/Codeaurora/platform_hardware_qcom_audio/-/blob/aee603282… > > alsa_mixer.c >> >> thanks, >> >> greg k-h > > -- > Best regards, > Coiby

1 0

[PATCH 0/2] regmap: add support to regmap_field_bulk_alloc/free
by Srinivas Kandagatla 25 Sep '20

25 Sep '20

Usage of regmap_field_alloc becomes much overhead when number of fields exceed more than 3. Most of driver seems to totally covered up with these allocs/free making to very hard to read the code! On such driver is QCOM LPASS driver has extensively converted to use regmap_fileds. This patchset add this new api and a user of it. Using new bluk api to allocate fields makes it much more cleaner code to read! Srinivas Kandagatla (2): regmap: add support to regmap_field_bulk_alloc/free apis ASoC: lpass-platform: use devm_regmap_field_bulk_alloc drivers/base/regmap/regmap.c | 100 ++++++++++++++++++++++++++++++++ include/linux/regmap.h | 11 ++++ sound/soc/qcom/lpass-platform.c | 31 +++------- 3 files changed, 118 insertions(+), 24 deletions(-) -- 2.21.0

2 4

alsaloop: Fix the silence generation in xrun_sync
by GitHub pull_request - opened 25 Sep '20

25 Sep '20

alsa-project/alsa-utils pull request #58 was opened from dragosht: The silence frames generation in xrun_sync() seems to be currently a bit off as snd_pcm_format_set_silence() uses a wrong buffer address and size for zero-ing out the data. Consequently instead of clearing out the last frame(s), snd_pcm_format_set_silence() ends up silencing samples somewhere else in the buffer. This is partilarly more obvious for higher frame size (e.g. when using more than 2 channels). This patch fixes this issue by correcting the parameters passed to snd_pcm_format_set_silence(). Signed-off-by: Dragos Tarcatu <dragos_tarcatu(a)mentor.com> Request URL : https://github.com/alsa-project/alsa-utils/pull/58 Patch URL : https://github.com/alsa-project/alsa-utils/pull/58.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[RFC PATCH 1/2] ASoC: cs47l15: Fix EPOUT->HPOUT1 Mono Mux routing
by Richard Fitzgerald 25 Sep '20

25 Sep '20

EPOUT is always mono so should have a permanent routing through the HPOUT1 Mono Mux. Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> --- sound/soc/codecs/cs47l15.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/cs47l15.c b/sound/soc/codecs/cs47l15.c index a591e7457d11..254f9d96e766 100644 --- a/sound/soc/codecs/cs47l15.c +++ b/sound/soc/codecs/cs47l15.c @@ -1089,6 +1089,7 @@ static const struct snd_soc_dapm_route cs47l15_dapm_routes[] = { { "HPOUT1 Demux", NULL, "OUT1R" }, { "OUT1R", NULL, "HPOUT1 Mono Mux" }, + { "HPOUT1 Mono Mux", "EPOUT", "OUT1L" }, { "HPOUTL", "HPOUT", "HPOUT1 Demux" }, { "HPOUTR", "HPOUT", "HPOUT1 Demux" }, @@ -1268,7 +1269,6 @@ static irqreturn_t cs47l15_adsp2_irq(int irq, void *data) static const struct snd_soc_dapm_route cs47l15_mono_routes[] = { { "HPOUT1 Mono Mux", "HPOUT", "OUT1L" }, - { "HPOUT1 Mono Mux", "EPOUT", "OUT1L" }, }; static int cs47l15_component_probe(struct snd_soc_component *component) -- 2.20.1

1 2

[PATCH v2] ALSA: hda - remove kerneldoc for internal hdac_i915 function
by Kai Vehmanen 24 Sep '20

24 Sep '20

Drop the kerneldoc markup for connectivity_check() as it's an static helper function. Fixes the following make W=1 warning: sound/hda/hdac_i915.c:80: warning: Function parameter or member 'i915' not described in 'connectivity_check' sound/hda/hdac_i915.c:80: warning: Function parameter or member 'hdac' not described in 'connectivity_check' Fixes: 7b882fe3e3e8 ('ALSA: hda - handle multiple i915 device instances') Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/hda/hdac_i915.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index d236e497435d..5f0a1aa6ad84 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -73,9 +73,7 @@ void snd_hdac_i915_set_bclk(struct hdac_bus *bus) } EXPORT_SYMBOL_GPL(snd_hdac_i915_set_bclk); -/** - * Returns true if the devices can be connected for audio. - */ +/* returns true if the devices can be connected for audio */ static bool connectivity_check(struct pci_dev *i915, struct pci_dev *hdac) { struct pci_bus *bus_a = i915->bus, *bus_b = hdac->bus; -- 2.27.0

2 1

[PATCH] ALSA: hda - add missing documentation to hdac_i915
by Kai Vehmanen 24 Sep '20

24 Sep '20

Document missing function arguments and fix make W=1 warning: sound/hda/hdac_i915.c:80: warning: Function parameter or member 'i915' not described in 'connectivity_check' sound/hda/hdac_i915.c:80: warning: Function parameter or member 'hdac' not described in 'connectivity_check' Fixes: 7b882fe3e3e8 ('ALSA: hda - handle multiple i915 device instances') Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/hda/hdac_i915.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index d236e497435d..9592d0c0c254 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -75,6 +75,8 @@ EXPORT_SYMBOL_GPL(snd_hdac_i915_set_bclk); /** * Returns true if the devices can be connected for audio. + * @i915: i915 PCI device + * @hdac: HDA audio controller PCI device */ static bool connectivity_check(struct pci_dev *i915, struct pci_dev *hdac) { -- 2.27.0

2 3

[PATCH] sound/soc/codecs: fix spelling typo in comments
by Wang Qing 24 Sep '20

24 Sep '20

Modify the comment typo: "compliment" -> "complement". Signed-off-by: Wang Qing <wangqing(a)vivo.com> --- sound/soc/codecs/ak4458.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/ak4458.h b/sound/soc/codecs/ak4458.h index f906215..e43144c --- a/sound/soc/codecs/ak4458.h +++ b/sound/soc/codecs/ak4458.h @@ -49,7 +49,7 @@ /* DIF2 1 0 * x 1 0 MSB justified Figure 3 (default) - * x 1 1 I2S Compliment Figure 4 + * x 1 1 I2S Complement Figure 4 */ #define AK4458_DIF_SHIFT 1 #define AK4458_DIF_MASK GENMASK(3, 1) -- 2.7.4

3 4