Vinod writes: soundwire updates for v5.3-rc1 Updates for 5.3 include: - module_sdw_driver macro for drivers - Documentation updates for code-blocks - Improvement from Pierre on intel and cadence driver - Clarification of DisCo properties and updates * tag 'soundwire-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: soundwire: add module_sdw_driver helper macro docs: soundwire: locking: fix tags for a code-block soundwire: intel_init: add checks on link numbers soundwire: fix typo in comments soundwire: Intel: add log for number of PCM and PDM PDIs soundwire: cadence_master: check the number of bidir PDIs soundwire: cadence_master: log Slave status mask on errors soundwire: cadence_master: use rate_limited dynamic debug soundwire: rename/clarify MIPI DisCo properties soundwire: clarify comment soundwire: mipi-disco: fix clock stop modes soundwire: rename 'freq' fields soundwire: mipi-disco: remove master_count property for masters soundwire: remove master data port properties soundwire: add port-related definitions soundwire: mipi_disco: fix master/link error soundwire: intel: filter SoundWire controller device search soundwire: cdns: Fix compilation error on arm64
Vinod writes: soundwire fixes for v5.2-rc4 Srinivas Kandagatla fixed by bunch of issues, two in core for locking and out of bound access and one in intel driver copy-paste * tag 'soundwire-5.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: soundwire: intel: set dai min and max channels correctly soundwire: stream: fix bad unlock balance soundwire: stream: fix out of boundary access on port properties
Looks like there is a copy paste error. This patch fixes it! Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org>
the msg lock is taken for multi-link cases only but released unconditionally, leading to an unlock balance warning for single-link usages This patch fixes this. ===================================== WARNING: bad unlock balance detected! 5.1.0-16506-gc1c383a6f0a2-dirty #1523 Tainted: G W ------------------------------------- aplay/2954 is trying to release lock (&bus->msg_lock) at: do_bank_switch+0x21c/0x480 but there are no more locks to release! Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by: Sanyog Kale <sanyog.r.kale@intel.com> [vkoul: edited the change log as suggested by Pierre] Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add mask to correctly read the SoundWire SHIM LCAP register. Only bits 2..0 are meaningful, the rest is about link synchronization and stream channel mapping. Without this mask, the hardware information would always be larger than whatever the BIOS would report. Also trap the case with zero links. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
Copy/paste of sdw_intel_res Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
This information will be reflected in debugfs but it's easier to see as a dmesg log. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
There is an assumption that the first two PDIs are reserved for Bulk, so we need to make sure the number of bidir PDIs is indeed larger than two. If the configuration provided is incorrect, this could lead to allocating a huge amount of memory. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
The Slave status mask exposes 4 sticky bits. When the device loses sync, the IP will report two status but the log will only show that the device lost sync. The status mask has all the information needed so let's report it instead. Also change the resolution of the mask, using 64 bits is not needed when you need 4. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
When commands start failing, e.g. due to a bad electrical connection or bus conflicts, the dmesg log is flooded. This should not happen for production devices but it's quite frequent when bringing-up a new platform. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>