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

[alsa-devel] [PATCH 0/2] ALSA: HDA: remove warnings with make W=1
by Pierre-Louis Bossart 14 Jan '20

14 Jan '20

Last series to make the sound subsystem report next to zero warnings (at least for the parts used by Intel). Pierre-Louis Bossart (2): ALSA: HDA: correct kernel-doc parameter descriptions ALSA: HDA: patch_hdmi: remove warnings with empty body sound/pci/hda/hda_codec.c | 1 + sound/pci/hda/hda_generic.c | 5 +++++ sound/pci/hda/hda_jack.c | 2 ++ sound/pci/hda/patch_ca0132.c | 1 + sound/pci/hda/patch_hdmi.c | 6 ++++-- 5 files changed, 13 insertions(+), 2 deletions(-) -- 2.20.1

2 4

[alsa-devel] [PATCH] ALSA: hda: Update kernel-doc function parameter descriptions
by Pierre-Louis Bossart 14 Jan '20

14 Jan '20

From: Keyon Jie <yang.jie(a)linux.intel.com> Make W=1 throws a lot of warnings, with multiple misalignments between function params and their descriptions. Signed-off-by: Keyon Jie <yang.jie(a)linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/hda/ext/hdac_ext_bus.c | 11 ++++++----- sound/hda/ext/hdac_ext_controller.c | 14 +++++++------- sound/hda/ext/hdac_ext_stream.c | 1 - sound/hda/hdac_bus.c | 3 +++ sound/hda/hdac_component.c | 1 + sound/hda/hdac_controller.c | 2 +- sound/hda/hdac_device.c | 12 ++++++++---- sound/hda/hdac_stream.c | 2 ++ 8 files changed, 28 insertions(+), 18 deletions(-) diff --git a/sound/hda/ext/hdac_ext_bus.c b/sound/hda/ext/hdac_ext_bus.c index 242306d820ec..73bfa71845f6 100644 --- a/sound/hda/ext/hdac_ext_bus.c +++ b/sound/hda/ext/hdac_ext_bus.c @@ -19,10 +19,10 @@ MODULE_LICENSE("GPL v2"); /** * snd_hdac_ext_bus_init - initialize a HD-audio extended bus - * @ebus: the pointer to extended bus object + * @bus: the pointer to HDAC bus object * @dev: device pointer * @ops: bus verb operators - * default ops + * @ext_ops: operators used for ASoC HDA codec drivers * * Returns 0 if successful, or a negative error code. */ @@ -51,7 +51,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_init); /** * snd_hdac_ext_bus_exit - clean up a HD-audio extended bus - * @ebus: the pointer to extended bus object + * @bus: the pointer to HDAC bus object */ void snd_hdac_ext_bus_exit(struct hdac_bus *bus) { @@ -67,8 +67,9 @@ static void default_release(struct device *dev) /** * snd_hdac_ext_bus_device_init - initialize the HDA extended codec base device - * @ebus: hdac extended bus to attach to + * @bus: hdac bus to attach to * @addr: codec address + * @hdev: hdac device to init * * Returns zero for success or a negative error code. */ @@ -114,7 +115,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_device_exit); /** * snd_hdac_ext_bus_device_remove - remove HD-audio extended codec base devices * - * @ebus: HD-audio extended bus + * @bus: the pointer to HDAC bus object */ void snd_hdac_ext_bus_device_remove(struct hdac_bus *bus) { diff --git a/sound/hda/ext/hdac_ext_controller.c b/sound/hda/ext/hdac_ext_controller.c index cfab60d88c92..a684f0520b4b 100644 --- a/sound/hda/ext/hdac_ext_controller.c +++ b/sound/hda/ext/hdac_ext_controller.c @@ -28,7 +28,7 @@ /** * snd_hdac_ext_bus_ppcap_enable - enable/disable processing pipe capability - * @ebus: HD-audio extended core bus + * @bus: the pointer to HDAC bus object * @enable: flag to turn on/off the capability */ void snd_hdac_ext_bus_ppcap_enable(struct hdac_bus *bus, bool enable) @@ -50,7 +50,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_ppcap_enable); /** * snd_hdac_ext_bus_ppcap_int_enable - ppcap interrupt enable/disable - * @ebus: HD-audio extended core bus + * @bus: the pointer to HDAC bus object * @enable: flag to enable/disable interrupt */ void snd_hdac_ext_bus_ppcap_int_enable(struct hdac_bus *bus, bool enable) @@ -77,7 +77,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_ppcap_int_enable); /** * snd_hdac_ext_bus_get_ml_capabilities - get multilink capability - * @ebus: HD-audio extended core bus + * @bus: the pointer to HDAC bus object * * This will parse all links and read the mlink capabilities and add them * in hlink_list of extended hdac bus @@ -117,7 +117,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_get_ml_capabilities); /** * snd_hdac_link_free_all- free hdac extended link objects * - * @ebus: HD-audio ext core bus + * @bus: the pointer to HDAC bus object */ void snd_hdac_link_free_all(struct hdac_bus *bus) @@ -134,7 +134,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_link_free_all); /** * snd_hdac_ext_bus_get_link_index - get link based on codec name - * @ebus: HD-audio extended core bus + * @bus: the pointer to HDAC bus object * @codec_name: codec name */ struct hdac_ext_link *snd_hdac_ext_bus_get_link(struct hdac_bus *bus, @@ -211,7 +211,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_link_power_down); /** * snd_hdac_ext_bus_link_power_up_all -power up all hda link - * @ebus: HD-audio extended bus + * @bus: the pointer to HDAC bus object */ int snd_hdac_ext_bus_link_power_up_all(struct hdac_bus *bus) { @@ -232,7 +232,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_link_power_up_all); /** * snd_hdac_ext_bus_link_power_down_all -power down all hda link - * @ebus: HD-audio extended bus + * @bus: the pointer to HDAC bus object */ int snd_hdac_ext_bus_link_power_down_all(struct hdac_bus *bus) { diff --git a/sound/hda/ext/hdac_ext_stream.c b/sound/hda/ext/hdac_ext_stream.c index 6b1b4b834bae..c4d54a838773 100644 --- a/sound/hda/ext/hdac_ext_stream.c +++ b/sound/hda/ext/hdac_ext_stream.c @@ -530,7 +530,6 @@ EXPORT_SYMBOL_GPL(snd_hdac_ext_stream_set_dpibr); /** * snd_hdac_ext_stream_set_lpib - sets the lpib value of a stream - * @bus: HD-audio core bus * @stream: hdac_ext_stream * @value: lpib value to set */ diff --git a/sound/hda/hdac_bus.c b/sound/hda/hdac_bus.c index 48b227fff204..3fe62be1cbcc 100644 --- a/sound/hda/hdac_bus.c +++ b/sound/hda/hdac_bus.c @@ -22,6 +22,7 @@ static const struct hdac_bus_ops default_ops = { /** * snd_hdac_bus_init - initialize a HD-audio bas bus * @bus: the pointer to bus object + * @dev: device pointer * @ops: bus verb operators * * Returns 0 if successful, or a negative error code. @@ -64,6 +65,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_bus_exit); /** * snd_hdac_bus_exec_verb - execute a HD-audio verb on the given bus * @bus: bus object + * @addr: the HDAC device address * @cmd: HD-audio encoded verb * @res: pointer to store the response, NULL if performing asynchronously * @@ -84,6 +86,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_bus_exec_verb); /** * snd_hdac_bus_exec_verb_unlocked - unlocked version * @bus: bus object + * @addr: the HDAC device address * @cmd: HD-audio encoded verb * @res: pointer to store the response, NULL if performing asynchronously * diff --git a/sound/hda/hdac_component.c b/sound/hda/hdac_component.c index dfe7e755f594..89126c6fd216 100644 --- a/sound/hda/hdac_component.c +++ b/sound/hda/hdac_component.c @@ -262,6 +262,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_acomp_register_notifier); /** * snd_hdac_acomp_init - Initialize audio component * @bus: HDA core bus + * @aops: audio component ops * @match_master: match function for finding components * @extra_size: Extra bytes to allocate * diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c index b856184af37f..bc4a8b606020 100644 --- a/sound/hda/hdac_controller.c +++ b/sound/hda/hdac_controller.c @@ -561,7 +561,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_bus_stop_chip); * snd_hdac_bus_handle_stream_irq - interrupt handler for streams * @bus: HD-audio core bus * @status: INTSTS register value - * @ask: callback to be called for woken streams + * @ack: callback to be called for woken streams * * Returns the bits of handled streams, or zero if no stream is handled. */ diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c index 7bcdb0e454f2..9a526aeef8da 100644 --- a/sound/hda/hdac_device.c +++ b/sound/hda/hdac_device.c @@ -135,7 +135,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_device_exit); /** * snd_hdac_device_register - register the hd-audio codec base device - * codec: the device to register + * @codec: the device to register */ int snd_hdac_device_register(struct hdac_device *codec) { @@ -158,7 +158,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_device_register); /** * snd_hdac_device_unregister - unregister the hd-audio codec base device - * codec: the device to unregister + * @codec: the device to unregister */ void snd_hdac_device_unregister(struct hdac_device *codec) { @@ -281,6 +281,10 @@ EXPORT_SYMBOL_GPL(snd_hdac_read); /** * _snd_hdac_read_parm - read a parmeter + * @codec: the codec object + * @nid: NID to read a parameter + * @parm: parameter to read + * @res: pointer to store the read value * * This function returns zero or an error unlike snd_hdac_read_parm(). */ @@ -1062,9 +1066,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_check_power_state); * snd_hdac_sync_power_state - wait until actual power state matches * with the target state * - * @hdac: the HDAC device + * @codec: the HDAC device * @nid: NID to send the command - * @target_state: target state to check for + * @power_state: target power state to wait for * * Return power state or PS_ERROR if codec rejects GET verb. */ diff --git a/sound/hda/hdac_stream.c b/sound/hda/hdac_stream.c index 682ed39f79b0..d01e69139164 100644 --- a/sound/hda/hdac_stream.c +++ b/sound/hda/hdac_stream.c @@ -590,7 +590,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_stream_timecounter_init); /** * snd_hdac_stream_sync_trigger - turn on/off stream sync register * @azx_dev: HD-audio core stream (master stream) + * @set: true = set, false = clear * @streams: bit flags of streams to sync + * @reg: the stream sync register address */ void snd_hdac_stream_sync_trigger(struct hdac_stream *azx_dev, bool set, unsigned int streams, unsigned int reg) -- 2.20.1

2 1

[alsa-devel] [PATCH] soundwire: intel: fix factor of two in MCLK handling
by Pierre-Louis Bossart 14 Jan '20

14 Jan '20

From: Bard Liao <yung-chuan.liao(a)linux.intel.com> Somehow Intel folks were confused, the property is 2x what the mclk frequency actually is (checked the actual bus frequency with a scope) Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- drivers/soundwire/intel.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index 0371d3d5501a..06ef3a3ac080 100644 --- a/drivers/soundwire/intel.c +++ b/drivers/soundwire/intel.c @@ -880,6 +880,9 @@ static int sdw_master_read_intel_prop(struct sdw_bus *bus) "intel-sdw-ip-clock", &prop->mclk_freq); + /* the values reported by BIOS are the 2x clock, not the bus clock */ + prop->mclk_freq /= 2; + fwnode_property_read_u32(link, "intel-quirk-mask", &quirk_mask); -- 2.20.1

2 1

[alsa-devel] [PATCH 0/2] soundwire: cadence: remove warnings
by Pierre-Louis Bossart 14 Jan '20

14 Jan '20

Fix warnings reported by cppcheck and make W=1 Pierre-Louis Bossart (2): soundwire: cadence: update kernel-doc parameter descriptions soundwire: cadence: remove useless variable incrementation drivers/soundwire/cadence_master.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.20.1

2 3

[alsa-devel] [PATCH v6 0/2] soundwire: Add support to Qualcomm SoundWire master
by Srinivas Kandagatla 14 Jan '20

14 Jan '20

Thanks for reviewing the v5 patchset. Here is new patchset addressing all the comments from v5 This patchset adds support for Qualcomm SoundWire Master Controller found in most of Qualcomm SoCs and WCD audio codecs. This driver along with WCD934x codec and WSA881x Class-D Smart Speaker Amplifier drivers is tested on on DragonBoard DB845c based of SDM845 SoC and Lenovo YOGA C630 Laptop based on SDM850. SoundWire controller on SDM845 is integrated in WCD934x audio codec via SlimBus interface. Currently this driver is very minimal and only supports PDM. Most of the code in this driver is rework of Qualcomm downstream drivers used in Andriod. Credits to Banajit Goswami and Patrick Lai's Team. TODO: Test and add PCM support. Thanks, srini Changes since v5: -No code changes. -Add extra comment in interrupt handler as suggested by Pierre Srinivas Kandagatla (2): dt-bindings: soundwire: add bindings for Qcom controller soundwire: qcom: add support for SoundWire controller .../bindings/soundwire/qcom,sdw.txt | 167 ++++ drivers/soundwire/Kconfig | 9 + drivers/soundwire/Makefile | 4 + drivers/soundwire/qcom.c | 861 ++++++++++++++++++ 4 files changed, 1041 insertions(+) create mode 100644 Documentation/devicetree/bindings/soundwire/qcom,sdw.txt create mode 100644 drivers/soundwire/qcom.c -- 2.21.0

2 3

[alsa-devel] [PATCH 0/6] soundwire: cadence: better logs and error handling
by Pierre-Louis Bossart 14 Jan '20

14 Jan '20

This is a stand-alone set of patches to improve error handling and provide better information to the platform integrator. As suggested by Vinod, these patches are shared first - with the risk that they are separated from the actual steps where they are needed. For reference, the complete set of 100+ patches required for SoundWire on Intel platforms is available here: https://github.com/thesofproject/linux/pull/1692 Pierre-Louis Bossart (4): soundwire: cadence_master: filter out bad interrupts soundwire: cadence_master: log more useful information during timeouts soundwire: cadence_master: handle multiple status reports per Slave soundwire: bus: check first if Slaves become UNATTACHED Rander Wang (2): soundwire: cadence_master: clear interrupt status before enabling interrupt soundwire: cadence_master: remove config update for interrupt setting drivers/soundwire/bus.c | 18 +++++++++ drivers/soundwire/cadence_master.c | 60 +++++++++++++++++++++++++----- 2 files changed, 68 insertions(+), 10 deletions(-) base-commit: b637124800a157c4df3699d1137d8533394f7678 -- 2.20.1

2 7

[alsa-devel] MIDI 2.0 universal packet protocol
by GitHub issues - edited 14 Jan '20

14 Jan '20

alsa-project/alsa-lib issue #24 was edited from symdeb: Since MIDI 2.0 only support USB and not over DIN (for now), will MIDI 2.0 need a new or updated OS class driver for the 32/64 bit universal packet interface and device descriptor for devices ? Page 16 of the USB MIDI class driver spec defines support for 1,2 or 3 bytes transfers only, How will this have to be implemented by MIDI USB device manufacturers and well as on the Linux OSes side ? How will this impact Linux ALSA ? Would the first byte of the message with b7=0 not confuse the driver of running status ? Link universal packet format https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-a…) Link first MIDI 2.0 Ready product: Roland A-88MKII https://www.midi.org/articles-old/roland-announces Issue URL : https://github.com/alsa-project/alsa-lib/issues/24 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[alsa-devel] MIDI 2.0 universal packet protocol
by GitHub issues - edited 14 Jan '20

14 Jan '20

alsa-project/alsa-lib issue #24 was edited from symdeb: Since MIDI 2.0 only support USB and not over DIN (for now), will MIDI 2.0 need a new or updated OS class driver for the 32/64 bit universal packet interface and device descriptor for devices ? Page 16 of the USB MIDI class driver spec defines support for 1,2 or 3 bytes transfers only, How will this have to be implemented by MIDI USB device manufacturers and well as on the Linux OSes side ? How will this impact Linux ALSA ? Would the first byte of the message with b7=0 not confuse the driver of running status ? Reference for packet format : [https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-a… Issue URL : https://github.com/alsa-project/alsa-lib/issues/24 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[alsa-devel] MIDI 2.0 universal packet protocol
by GitHub issues - opened 14 Jan '20

14 Jan '20

alsa-project/alsa-lib issue #24 was opened from symdeb: Since MIDI 2.0 only support USB and non MIDI DIN (for now), will MIDI 2.0 need a new or updated OS class driver for the 32/64 bit universal packet interface and device descriptor for devices ? Page 16 of the USB MIDI class driver spec defines support for 1,2 or 3 bytes transfers only, How will this have to be implemented by MIDI USB device manufacturers and well as on the Linux OSes side ? How will this impact Linux ALSA ? Would the first byte of the message with b7=0 not confuse the driver of running status ? Reference for packet format : [https://www.midi.org/articles-old/details-about-midi-2-0-midi-ci-profiles-a… Issue URL : https://github.com/alsa-project/alsa-lib/issues/24 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Re: [alsa-devel] Github MOTU PCI 324; Motu 2408; Motu 1224
by Takashi Sakamoto 14 Jan '20

14 Jan '20

Hi Yan, (CCed to alsa-devel) On Tue, Jan 14, 2020, at 02:07, Yannic Korten wrote: > Hey Mr. Takashi, > I'm new to Linux and new to Github. If you think this is spam or you > wanted to be in private: See this mail as spam - ignore and just delete > it. I'm sorry then. > But I have a problem and don't know whom to contact. It seems like you > have much experience with coding and the usage of ALSA (which seems to > be your project). > So, my setup is the following: > Ubuntu Studio 19.10 > MOTU 324 PCI Card (detected as 'Multimedia audio controller: Mark of > the Unicorn Inc PCI-324 Audiowire Interface (rev 0a)') > MOTU 1224 > MOTU 2408 > So I tried to install your files from github but it seems not to be > working. Either it's because it's just the support for some newer MOTU > devices or I'm to dumb. > Is it possible to get the above devices fully running on linux with > your "drivers"? Or are they not supporting? > Will it be possible to insert them to the code (easily)? Or is it way > to much expenditure for that old devices? > > Thanks for help > Greetings from Germany > Yan I'm an author/maintainer of ALSA firewire stack which includes snd-firewire-motu driver. The driver can handle MOTU's FireWire series for IEEE 1394 bus; e.g. MOTU 828mkII. Unfortunately, the driver is unavailable for your model. Your model is not compliant to IEEE 1394. It's for 'AudioWire', which is proprietary protocol developed by MOTU. Like 1394 OHCI card is for IEEE 1394 bus, PCI-324/424 ASIC card is for 'AudioWire'. The ASIC is designed by MOTU itself (Precisely S&S Research, Inc.) and the detail is closed. Although PCI-324/424 card has physical ports into which IEEE 1394 cables can connect, and actually AudioWire uses the same cable of IEEE 1394a, signals in the cable is completely different from IEEE 1394. In the summer of 2015, I bought AudioWire-based model (it's really cheep in used market) and attempted to connect it to my IEEE 1394 bus analyzer. As I expected, nothing can be detected. I guess that PCI-324/424 ASIC integrates a sort of computing core (e.g. ARM7TDMI) with PCI interface for AudioWire protocol. For this kind of device, people need to work for reverse-engineering by analyze MOTU driver's behaviour in memory space mapped to host system, and write new driver to emulate the behaviour. However, this is a kind of 'adventure' and no guarantee to achieve. On the other hand, it certainly consumes the batch of developer's resources, unless getting enough assists by vendors. This is a reason that you cannot see AudioWire compliant drivers as Open Source Software. Regards Takashi Sakamoto

1 0