summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-10-17ALSA: firewire-digi00x: use the same size of period for PCM substream in ↵Takashi Sakamoto1-7/+28
AMDTP streams In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. I note that DOT AMDTP protocol has a quirk to use different transmission method of IEC 61883-6 for tx/rx streams; non-blocking in tx stream and blocking in rx stream. Although the difference of transmission method between tx/rx streams precisely brings different timing for a certain amount of events due to their different calculation for data blocks per packet, it's possible to approximate enough amount of events mostly has the same timing. Actually current ALSA IEC 61883-1/6 engine uses large amount of data blocks for each hardware IRQ (=16 packets). Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-15-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: dice: use the same size of period for PCM substream in AMDTP streamsTakashi Sakamoto1-12/+31
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Dice hardware has a quirk called as 'Dual Wire'. For a case of higher sampling transmission frequency, this commit performs calculations between the number of PCM frames and the number of events in AMDTP stream. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-14-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: oxfw: use the same size of period for PCM substream in AMDTP streamsTakashi Sakamoto1-11/+28
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-13-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: fireworks: use the same size of period for PCM substream in AMDTP streamsTakashi Sakamoto1-11/+28
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-12-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: bebob: use the same size of period for PCM substream in AMDTP streamsTakashi Sakamoto1-12/+27
In current implementation, when opening a PCM substream, it's needed to check whether the opposite PCM substream runs. This is to assign effectual constraints (e.g. sampling rate) to opened PCM substream. The number of PCM substreams and MIDI substreams on AMDTP streams in domain is recorded in own structure. Usage of this count is an alternative of the above check. This is better because the count is incremented in pcm.hw_params earlier than pcm.trigger. This idea has one issue because it's incremented for MIDI substreams as well. In current implementation, for a case that any MIDI substream run and a PCM substream is going to start, PCM application to start the PCM substream can decide hardware parameters by restart packet streaming. Just checking the substream count can brings regression. Now AMDTP domain structure has a member for the size of PCM period in PCM substream which starts AMDTP streams in domain. When the value has zero and the substream count is greater than 1, it means that any MIDI substream starts AMDTP streams in domain. Usage of the value can resolve the above issue. This commit replaces the check with the substream count and the value for the size of PCM period. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-11-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: fireface: register the size of PCM period to AMDTP domainTakashi Sakamoto3-3/+14
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-10-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-motu: register the size of PCM period to AMDTP domainTakashi Sakamoto4-4/+16
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-9-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-tascam: register the size of PCM period to AMDTP domainTakashi Sakamoto3-3/+15
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-8-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-digi00x: register the size of PCM period to AMDTP domainTakashi Sakamoto4-4/+16
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-7-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: dice: register the size of PCM period to AMDTP domainTakashi Sakamoto4-4/+16
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-6-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: oxfw: register the size of PCM period to AMDTP domainTakashi Sakamoto4-6/+19
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: fireworks: register the size of PCM period to AMDTP domainTakashi Sakamoto4-4/+16
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: bebob: register the size of PCM period to AMDTP domainTakashi Sakamoto4-4/+16
This commit is a preparation to share the size of PCM period between PCM substreams on AMDTP streams in the same domain. At this time, the size of PCM period in PCM substream which starts AMDTP streams in the same domain is recorded. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: firewire-lib: add a member into AMDTP domain for events per periodTakashi Sakamoto2-0/+14
In IEC 61883-6, it's called as 'event' what has presentation time represented by timestamp in CIP header. Although the ratio of the number of event against the number of data block is different depending on event data type represented by the specific field in CIP header, it's just one in the most cases supported by ALSA IEC 61883-1/6 engine. In 1394 OHCI specification, applications can schedule hardware IRQ by configuring descriptor with IRQ flag for packet against each isochronous cycle. For future commit, I use the hardware IRQ for isoc IT context to acknowledge the elapse of PCM period for both playback/capture directions on AMDTP streams in the same domain. This commit is a preparation for the above idea. This commit adds a member into AMDTP domain structure to record the number of PCM frames. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191007110532.30270-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: hda/realtek - Enable headset mic on Asus MJ401TADaniel Drake1-0/+11
On Asus MJ401TA (with Realtek ALC256), the headset mic is connected to pin 0x19, with default configuration value 0x411111f0 (indicating no physical connection). Enable this by quirking the pin. Mic jack detection was also tested and found to be working. This enables use of the headset mic on this product. Signed-off-by: Daniel Drake <drake@endlessm.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191017081501.17135-1-drake@endlessm.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-17ALSA: usb-audio: Disable quirks for BOSS Katana amplifiersSzabolcs Szőke1-0/+3
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@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191011171937.8013-1-szszoke.code@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-10-16ASoC: rt1011: Read and apply r0 and temperature device propertyShuming Fan2-1/+41
Typically, the r0 (calibration data) and temperature were measured in the factory. This information is written into the non-volatile area where keeps data whether factory reset or OS update. In Chromium OS case, the coreboot will read the info from VPD and create the device property for each rt1011. Signed-off-by: Shuming Fan <shumingf@realtek.com> Tested-By: Cheng-Yi Chiang <cychiang@chromium.org> Link: https://lore.kernel.org/r/20191016085845.11672-1-shumingf@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-16ASoC: dt-bindings: rt1011: add r0 and temperature device propertyShuming Fan1-0/+10
Typically, the r0 (calibration data) and temperature were measured in the factory. This information is written into the non-volatile area where keeps data whether factory reset or OS update. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191016115617.23213-1-shumingf@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-16ASoC: wm8958: use <asm/unaligned.h> to simplify codeBen Dooks (Codethink)1-13/+9
Simplify the memcpy/be32_to_cpu() code by simply using get_unaligned_be32() throughout and makes the code nicer to look at. This fixes the following warnings from sparse: sound/soc/codecs/wm8958-dsp2.c:62:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:62:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:62:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:62:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:62:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:62:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:69:15: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:69:15: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:69:15: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:69:15: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:69:15: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:69:15: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:72:18: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:72:18: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:72:18: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:72:18: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:72:18: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:72:18: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:91:17: warning: cast to restricted __be64 sound/soc/codecs/wm8958-dsp2.c:91:17: warning: cast to restricted __be64 sound/soc/codecs/wm8958-dsp2.c:91:17: warning: cast to restricted __be64 sound/soc/codecs/wm8958-dsp2.c:91:17: warning: cast to restricted __be64 sound/soc/codecs/wm8958-dsp2.c:91:17: warning: cast to restricted __be64 sound/soc/codecs/wm8958-dsp2.c:91:17: warning: cast to restricted __be64 sound/soc/codecs/wm8958-dsp2.c:91:17: warning: cast to restricted __be64 sound/soc/codecs/wm8958-dsp2.c:91:17: warning: cast to restricted __be64 sound/soc/codecs/wm8958-dsp2.c:91:17: warning: cast to restricted __be64 sound/soc/codecs/wm8958-dsp2.c:91:17: warning: cast to restricted __be64 sound/soc/codecs/wm8958-dsp2.c:108:29: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:108:29: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:108:29: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:108:29: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:108:29: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:108:29: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:120:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:120:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:120:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:120:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:120:26: warning: cast to restricted __be32 sound/soc/codecs/wm8958-dsp2.c:120:26: warning: cast to restricted __be32 Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20191016120149.5860-1-ben.dooks@codethink.co.uk Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-16ASoC: rt1011: set tx/rx slots from tx/rx_mask in TDM caseShuming Fan2-5/+160
The TX/RX slot configuration use tx/rx_mask which requested by the machine driver. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191016085754.11614-1-shumingf@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-15ASoC: pcm3168a: Fix serial mode dependent format supportPeter Ujfalusi1-3/+0
fmt 0 is perfectly valid (PCM3168A_FMT_I2S). Remove the return in case fmt == 0. Fixes: ("ASoC: pcm3168a: Use fixup instead of constraint for channels and formats") Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20191015090037.23271-1-peter.ujfalusi@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-15ASoC: audio-graph: fixup graph_dai_link_of_dpcm() commentKuninori Morimoto1-2/+2
The comment is wrong. This patch fixup it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/87eeze67p7.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-15ASoC: sof: include types.h at header.hKuninori Morimoto1-0/+1
Content-Transfer-Encoding: 8bit Without <types.h> we will get these error linux/include/sound/sof/header.h:125:2: error: unknown type name ‘uint32_t’uint32_t size; linux/include/sound/sof/header.h:136:2: error: unknown type name ‘uint32_t’uint32_t size; linux/include/sound/sof/header.h:137:2: error: unknown type name ‘uint32_t’uint32_t cmd; ... linux/include/sound/sof/dai-imx.h:18:2: error: unknown type name ‘uint16_t’uint16_t reserved1; linux/include/sound/sof/dai-imx.h:30:2: error: unknown type name ‘uint16_t’uint16_t tdm_slot_width; linux/include/sound/sof/dai-imx.h:31:2: error: unknown type name ‘uint16_t’uint16_t reserved2; Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87a7a24l7r.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-15ASoC: simple-card: fixup simple_dai_link_of_dpcm() commentKuninori Morimoto1-2/+2
The comment is wrong. This patch fixup it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/87ftju67pi.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-15ASoC: Intel: eve: Enable mclk and ssp sclk earlyNaveen M2-0/+95
rt5663 and rt5514 needs mclk/sclk early to synchronize its internal clocks. Signed-off-by: Naveen M <naveen.m@intel.com> Signed-off-by: Harsha Priya <harshapriya.n@intel.com> Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com> Signed-off-by: Brent Lu <brent.lu@intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/1571070480-25666-1-git-send-email-brent.lu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-14ASoC: SOF: Fix randbuild errorYueHaibing1-0/+2
When LEDS_TRIGGER_AUDIO is m and SND_SOC_SOF is y, sound/soc/sof/control.o: In function `snd_sof_switch_put': control.c:(.text+0x587): undefined reference to `ledtrig_audio_set' control.c:(.text+0x593): undefined reference to `ledtrig_audio_set' Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 5d43001ae436 ("ASoC: SOF: acpi led support for switch controls") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191014091308.23688-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-14ASoC: SOF: topology: check errors when parsing LED tokensPierre-Louis Bossart1-0/+5
sof_parse_tokens() returns a value that is checked on every call except for LED tokens, fix with explicit test. Detected with cppcheck warning: sound/soc/sof/topology.c:973:6: style: Variable 'ret' is assigned a value that is never used. [unreadVariable] ret = sof_parse_tokens(scomp, &scontrol->led_ctl, led_tokens, ^ Fixes: 5d43001ae4360 ("ASoC: SOF: acpi led support for switch controls") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191011164312.7988-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-14ASoC: SOF: topology: remove always-true redundant testPierre-Louis Bossart1-4/+3
Address cppcheck warning: sound/soc/sof/topology.c:2322:6: style: Condition 'pcm' is always true [knownConditionTrueFalse] if (pcm) { ^ sound/soc/sof/topology.c:2311:6: note: Assuming that condition '!pcm' is not redundant if (!pcm) ^ sound/soc/sof/topology.c:2322:6: note: Condition 'pcm' is always true if (pcm) { ^ Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191011164312.7988-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-14ASoC: SOF: Intel: bdw: fix operator precedence warningsPierre-Louis Bossart1-8/+8
Address cppcheck warnings sound/soc/sof/intel/bdw.c:265:26: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] panic & SHIM_IPCX_BUSY ? "yes" : "no", ^ sound/soc/sof/intel/bdw.c:266:26: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] panic & SHIM_IPCX_DONE ? "yes" : "no", panic); ^ sound/soc/sof/intel/bdw.c:269:25: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] imrx & SHIM_IMRX_BUSY ? "yes" : "no", ^ sound/soc/sof/intel/bdw.c:270:25: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] imrx & SHIM_IMRX_DONE ? "yes" : "no", imrx); ^ sound/soc/sof/intel/bdw.c:273:27: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] status & SHIM_IPCD_BUSY ? "yes" : "no", ^ sound/soc/sof/intel/bdw.c:274:27: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] status & SHIM_IPCD_DONE ? "yes" : "no", status); ^ sound/soc/sof/intel/bdw.c:277:25: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] imrd & SHIM_IMRD_BUSY ? "yes" : "no", ^ sound/soc/sof/intel/bdw.c:278:25: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] imrd & SHIM_IMRD_DONE ? "yes" : "no", imrd); ^ Fixes: 3a9e204d4e369 ("ASoC: SOF: Intel: Add context data to any IPC timeout.") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191011164312.7988-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-14ASoC: SOF: Intel: byt: fix operator precedence warningsPierre-Louis Bossart1-8/+8
Address cppcheck warnings sound/soc/sof/intel/byt.c:163:26: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] panic & SHIM_IPCX_BUSY ? "yes" : "no", ^ sound/soc/sof/intel/byt.c:164:26: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] panic & SHIM_IPCX_DONE ? "yes" : "no", panic); ^ sound/soc/sof/intel/byt.c:167:25: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] imrx & SHIM_IMRX_BUSY ? "yes" : "no", ^ sound/soc/sof/intel/byt.c:168:25: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] imrx & SHIM_IMRX_DONE ? "yes" : "no", imrx); ^ sound/soc/sof/intel/byt.c:171:27: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] status & SHIM_IPCD_BUSY ? "yes" : "no", ^ sound/soc/sof/intel/byt.c:172:27: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] status & SHIM_IPCD_DONE ? "yes" : "no", status); ^ sound/soc/sof/intel/byt.c:175:25: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] imrd & SHIM_IMRD_BUSY ? "yes" : "no", ^ sound/soc/sof/intel/byt.c:176:25: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] imrd & SHIM_IMRD_DONE ? "yes" : "no", imrd); ^ Fixes: 3a9e204d4e369 ("ASoC: SOF: Intel: Add context data to any IPC timeout.") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191011164312.7988-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-14ASoC: fsl_mqs: Move static keyword to the front of declarationsYueHaibing1-1/+1
gcc warn about this: sound/soc/fsl/fsl_mqs.c:146:1: warning: static is not at beginning of declaration [-Wold-style-declaration] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Nicolin Chen <nicoleotsuka@gmail.com> Link: https://lore.kernel.org/r/20191011143538.15300-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-14ASoC: adau7118: Fix Kconfig warning without CONFIG_I2CYueHaibing1-0/+1
When building a kernel without CONFIG_I2C, Kconfig warns: WARNING: unmet direct dependencies detected for REGMAP_I2C Depends on [n]: I2C [=n] Selected by [y]: - SND_SOC_ADAU7118_I2C [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] Add missing I2C dependency to SND_SOC_ADAU7118_I2C to fix this. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: ca514c0f12b0 ("ASOC: Add ADAU7118 8 Channel PDM-to-I2S/TDM Converter driver") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20191011150042.20096-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-14ASoC: stm32: spdifrx: retry synchronization in sync stateOlivier Moysan1-2/+16
When STM32 SPDIFRX is in sync state, allow multiple synchro attempts, instead of exiting on first unsuccessful trial. This is useful when spdif signal is not immediately available on input. This also allows Pulseaudio to check iec capture device availability when no signal is present. Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20191011084816.14279-1-olivier.moysan@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10ASoC: tas2562: Introduce the TAS2562 amplifierDan Murphy4-0/+682
Introduce the Texas Instruments TAS2562 amplifier driver with I/V sense for loud speaker applications. http://www.ti.com/lit/gpn/tas2562 Signed-off-by: Dan Murphy <dmurphy@ti.com> Link: https://lore.kernel.org/r/20191008181517.5332-2-dmurphy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10ASoC: SOF: imx: Read ESAI parameters and send them to DSPDaniel Baluta2-2/+75
ESAI parameters are read for topology file, packed into sof_ipc_dai_esai_parms struct and then sent to DSP. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10ASoC: SOF: acpi led support for switch controlsJaska Uimonen4-0/+58
Currently sof doesn't support acpi leds with mute switches. So implement acpi leds following quite shamelessly existing HDA implementation by Takashi Iwai. Mute leds can be enabled in topology by adding led and direction token in switch control private data. Signed-off-by: Jaska Uimonen <jaska.uimonen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-10-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10ASoC: SOF: imx: Describe ESAI parameters to be sent to DSPDaniel Baluta4-3/+38
Introduce sof_ipc_dai_esai_params to keep information that we get from topology and we send to DSP FW. Also bump the ABI minor to reflect the changes on DSP FW. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10ASoC: SOF: pci: add debug module paramPierre-Louis Bossart1-1/+11
Add debug parameter for snd-sof-pci. One of the usages for this debug parameter to disable pm_runtime, which can be useful for platform bringup, or keep the parent device active while enabling pm_runtime for child devices (e.g. with SoundWire or MFD). This can also be useful to measure suspend-resume latencies or child devices. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10ASoC: SOF: acpi: add debug module paramPierre-Louis Bossart1-1/+11
Add debug parameter for snd-sof-acpi. One of the usages for this debug parameter to disable pm_runtime, which can be useful for platform bringup, or keep the parent device active while enabling pm_runtime for child devices (e.g. with SoundWire or MFD). This can also be useful to measure suspend-resume latencies or child devices. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10Revert "ASoC: SOF: Force polling mode on CFL and CNL"Kai Vehmanen1-7/+0
This reverts commit 64ca9d9fcb3e3c86b1417e3d17a90b43dd660f81. The workaround is no longer needed after configuring HDAC bus with sync_write=1. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10AsoC: SOF: refactor control load codeJaska Uimonen1-157/+157
Move code around to enable token parsing in control load. Signed-off-by: Jaska Uimonen <jaska.uimonen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10ASoC: SOF: enable dual control for pgaJaska Uimonen1-2/+3
Currently sof pga element supports only 1 kcontrol and you can't create for example a mixer element with combined volume slider and mute switch. So enable sof pga to have more than 1 kcontrol associated with it. Also check for possible NULL tlv pointer as switch element might not have it. Signed-off-by: Jaska Uimonen <jaska.uimonen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10ASoC: SOF: enable sync_write in hdac_busKai Vehmanen1-0/+1
Align SOF HDA implementation with snd-hda-intel driver and enable sync_write flag for all supported Intel platforms in SOF. When set, a sync is issued after each verb write. Sync after write has helped to overcome intermittent delays in system resume flow on Intel Coffee Lake systems, and most recently probe errors related to the HDMI codec on Ice Lake systems. Matches the snd-hda-intel driver change done in commit 2756d9143aa5 ("ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"). Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10dt-bindings: asoc: Add ADAU7118 documentationNuno Sá1-0/+90
Document the ADAU7118 8 channel PDM to I2S/TDM converter devicetree bindings. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20191010074234.7344-2-nuno.sa@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-10ASOC: Add ADAU7118 8 Channel PDM-to-I2S/TDM Converter driverNuno Sá7-0/+770
This patch adds support for the 8 channel PDM-to-I2S/TDM converter. The ADAU7118 converts four stereo pulse density modulation (PDM) bitstreams into one pulse code modulation (PCM) output stream. The source for the PDM data can be eight microphones or other PDM sources. The PCM audio data is output on a serial audio interface port in either inter-IC serial (I2S) or time domain multiplexed (TDM) format. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20191010074234.7344-1-nuno.sa@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-09ASoC: simple_card_utils.h: Add missing includeDaniel Baluta1-0/+1
When debug is enabled compiler cannot find the definition of clk_get_rate resulting in the following error: ./include/sound/simple_card_utils.h:168:40: note: previous implicit declaration of ‘clk_get_rate’ was here dev_dbg(dev, "%s clk %luHz\n", name, clk_get_rate(dai->clk)); ./include/sound/simple_card_utils.h:168:3: note: in expansion of macro ‘dev_dbg’ dev_dbg(dev, "%s clk %luHz\n", name, clk_get_rate(dai->clk)); Fix this by including the appropriate header. Fixes: 0580dde59438686d ("ASoC: simple-card-utils: add asoc_simple_debug_info()") Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20191009153615.32105-2-daniel.baluta@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-09ASoc: Add Texas Instruments TAS2562 amplifier bindingDan Murphy1-0/+34
Add the DT binding for the TAS2562 amplifier. Signed-off-by: Dan Murphy <dmurphy@ti.com> Link: https://lore.kernel.org/r/20191008181517.5332-1-dmurphy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-09ASoC: simple_card_utils.h: Fix potential multiple redefinition errorDaniel Baluta1-4/+4
asoc_simple_debug_info and asoc_simple_debug_dai must be static otherwise we might a compilation error if the compiler decides not to inline the given function. Fixes: 0580dde59438686d ("ASoC: simple-card-utils: add asoc_simple_debug_info()") Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20191009153615.32105-3-daniel.baluta@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-09ASoC: msm8916-wcd-digital: add missing MIX2 path for RX1/2Srinivas Kandagatla1-0/+22
This patch adds missing MIX2 path on RX1/2 which take IIR1 and IIR2 as inputs. Without this patch sound card fails to intialize with below warning: ASoC: no sink widget found for RX1 MIX2 INP1 ASoC: Failed to add route IIR1 -> IIR1 -> RX1 MIX2 INP1 ASoC: no sink widget found for RX2 MIX2 INP1 ASoC: Failed to add route IIR1 -> IIR1 -> RX2 MIX2 INP1 ASoC: no sink widget found for RX1 MIX2 INP1 ASoC: Failed to add route IIR2 -> IIR2 -> RX1 MIX2 INP1 ASoC: no sink widget found for RX2 MIX2 INP1 ASoC: Failed to add route IIR2 -> IIR2 -> RX2 MIX2 INP1 Reported-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20191009111944.28069-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-09ASoC: jz4740: Remove unused match variableStephen Boyd1-1/+0
After commit 67ad656bdd70 ("ASoC: jz4740: Use of_device_get_match_data()"), the match local variable is unused and the compiler rightly warns. sound/soc/jz4740/jz4740-i2s.c: In function 'jz4740_i2s_dev_probe': sound/soc/jz4740/jz4740-i2s.c:500:29: warning: unused variable 'match' [-Wunused-variable] 500 | const struct of_device_id *match; Drop it. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Paul Cercueil <paul@crapouillou.net> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: <alsa-devel@alsa-project.org> Fixes: 67ad656bdd70 ("ASoC: jz4740: Use of_device_get_match_data()") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20191008235212.228856-1-swboyd@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-01 11:34:15 +0300