summaryrefslogtreecommitdiffstats
path: root/drivers/soundwire (follow)
Commit message (Collapse)AuthorAgeFilesLines
* soundwire: stream: Add missing clear of alloc_slave_rtCharles Keepax2023-06-081-1/+3
| | | | | | | | | | | | The current path that skips allocating the slave runtime does not clear the alloc_slave_rt flag, this is clearly incorrect. Add the missing clear, so the runtime won't be erroneously cleaned up. Fixes: f3016b891c8c ("soundwire: stream: sdw_stream_add_ functions can be called multiple times") Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230602101140.2040141-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: qcom: add proper error paths in qcom_swrm_startup()Krzysztof Kozlowski2023-05-271-4/+13
| | | | | | | | | | Reverse actions in qcom_swrm_startup() error paths to avoid leaking stream memory and keeping runtime PM unbalanced. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230517163736.997553-1-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: dmi-quirks: add new mapping for HP Spectre x360Pierre-Louis Bossart2023-05-271-0/+7
| | | | | | | | | | | | A BIOS/DMI update seems to have broken some devices, let's add a new mapping. Link: https://github.com/thesofproject/linux/issues/4323 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230515074859.3097-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel_auxdevice: improve pm_prepare stepPierre-Louis Bossart2023-04-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | In the case where multiple peripherals are attached on the same link, it's possible that they are in different pm_runtime states. The device_for_each_child() loop to resume all devices before a system suspend would not work if one peripheral was active and others suspended. pm_runtime_resume() returns 1 in the former case, which is taken as a error. As a result, a pm_runtime suspended device might be skipped if the first device was active. This patch changes the behavior of the helper function to only return zero or a negative error. A Fixes tag is not provided since there are no existing configurations on Intel platforms with different types of devices on the same link. Amplifiers may be used on the same link, but they are used by the same dailink so their pm_runtime state is always matching. This assumption may not be true in the future, so we should improve the behavior and align with AMD. Reported-by: Mukunda,Vijendar <vijendar.mukunda@amd.com> Link: https://lore.kernel.org/lkml/4cbbff8a-c596-e9cc-a6cf-6f8b66607505@amd.com/ Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230323025228.1537107-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflowRichard Fitzgerald2023-04-121-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 443a98e649b4 ("soundwire: bus: use pm_runtime_resume_and_get()") Change calls to pm_runtime_resume_and_get() back to pm_runtime_get_sync(). This fixes a usage count underrun caused by doing a pm_runtime_put() even though pm_runtime_resume_and_get() returned an error. The three affected functions ignore -EACCES error from trying to get pm_runtime, and carry on, including a put at the end of the function. But pm_runtime_resume_and_get() does not increment the usage count if it returns an error. So in the -EACCES case you must not call pm_runtime_put(). The documentation for pm_runtime_get_sync() says: "Consider using pm_runtime_resume_and_get() ... as this is likely to result in cleaner code." In this case I don't think it results in cleaner code because the pm_runtime_put() at the end of the function would have to be conditional on the return value from pm_runtime_resume_and_get() at the top of the function. pm_runtime_get_sync() doesn't have this problem because it always increments the count, so always needs a put. The code can just flow through and do the pm_runtime_put() unconditionally. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230406134640.8582-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: don't save hw_params for use in preparePierre-Louis Bossart2023-04-122-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing code copies the hw_params pointer and reuses it later in .prepare, specifically to re-initialize the ALH DMA channel information that's lost in suspend-resume cycles. This is not needed, we can directly access the information from the substream/rtd - as done for the HDAudio DAIs in sound/soc/sof/intel/hda-dai.c In addition, using the saved pointer causes the suspend-resume test cases to fail on specific platforms, depending on which version of GCC is used. Péter Ujfalusi and I have spent long hours to root-cause this problem that was reported by the Intel CI first with 6.2-rc1 and again v6.3-rc1. In the latter case we were lucky that the problem was 100% reproducible on local test devices, and found out that adding a dev_dbg() or adding a call to usleep_range() just before accessing the saved pointer "fixed" the issue. With errors appearing just by changing the compiler version or minor changes in the code generated, clearly we have a memory management Heisenbug. The root-cause seems to be that the hw_params pointer is not persistent. The soc-pcm code allocates the hw_params structure on the stack, and passes it to the BE dailink hw_params and DAIs hw_params. Saving such a pointer and reusing it later during the .prepare stage cannot possibly work reliably, it's broken-by-design since v5.10. It's astonishing that the problem was not seen earlier. This simple fix will have to be back-ported to -stable, due to changes to avoid the use of the get/set_dmadata routines this patch will only apply on kernels older than v6.1. Fixes: a5a0239c27fe ("soundwire: intel: reinitialize IP+DSP in .prepare(), but only when resuming") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230321022642.1426611-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: bus: Update sdw_nread/nwrite_no_pm to handle page boundariesCharles Keepax2023-04-121-24/+39
| | | | | | | | | | | | | | | | | | | | Currently issuing a sdw_nread/nwrite_no_pm across a page boundary will silently fail to write correctly as nothing updates the page registers, meaning the same page of the chip will get rewritten with each successive page of data. As the sdw_msg structure contains page information it seems reasonable that a single sdw_msg should always be within one page. It is also mostly simpler to handle the paging at the bus level rather than each master having to handle it in their xfer_msg callback. As such add handling to the bus code to split up a transfer into multiple sdw_msg's when they go across page boundaries. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230322164948.566962-3-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: bus: Update kernel doc for no_pm functionsCharles Keepax2023-04-121-0/+37
| | | | | | | | | | | | | | | The kernel doc should really have been updated when the no_pm versions of the sdw_write/read functions were exported in commits: commit 167790abb90f ("soundwire: export sdw_write/read_no_pm functions") commit 62dc9f3f2fd0 ("soundwire: bus: export sdw_nwrite_no_pm and sdw_nread_no_pm functions") Add the missing kernel doc. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230322164948.566962-2-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: bus: Remove now outdated comments on no_pm IOCharles Keepax2023-04-121-3/+0
| | | | | | | | | | | | | | | Things have moved more towards end drivers using the no_pm versions of the IO functions. See commits: commit 167790abb90f ("soundwire: export sdw_write/read_no_pm functions") commit 62dc9f3f2fd0 ("soundwire: bus: export sdw_nwrite_no_pm and sdw_nread_no_pm functions") As such this comment is now misleading, so remove it. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230322164948.566962-1-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: stream: uniquify dev_err() logsPierre-Louis Bossart2023-04-121-8/+10
| | | | | | | | | | | There are a couple of duplicate logs which makes harder than needed to follow the error flows. Add __func__ or make the log unique. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230322035524.1509029-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: stream: remove bus->dev from logs on multiple busesPierre-Louis Bossart2023-04-121-2/+2
| | | | | | | | | | | A stream may depend on multiple managers/buses, e.g. for the multiple amplifier case. It's incorrect to use bus->dev in this case. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230322035524.1509029-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: amd: add pm_prepare callback and pm ops supportVijendar Mukunda2023-04-121-0/+84
| | | | | | | | | | | | Add pm_prepare callback and System level pm ops support for AMD SoundWire manager driver. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Signed-off-by: Mastan Katragadda <Mastan.Katragadda@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/lkml/20230310162554.699766-9-Vijendar.Mukunda@amd.com Link: https://lore.kernel.org/r/20230321050901.115439-9-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: amd: handle SoundWire wake enable interruptVijendar Mukunda2023-04-122-0/+11
| | | | | | | | | | | | Add wake enable interrupt support for both the SoundWire manager instances. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Signed-off-by: Mastan Katragadda <Mastan.Katragadda@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/lkml/20230227154801.50319-8-Vijendar.Mukunda@amd.com Link: https://lore.kernel.org/r/20230321050901.115439-8-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: amd: add runtime pm ops for AMD SoundWire manager driverVijendar Mukunda2023-04-122-0/+143
| | | | | | | | | | | Add support for runtime pm ops for AMD SoundWire manager driver. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Signed-off-by: Mastan Katragadda <Mastan.Katragadda@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/lkml/20230227154801.50319-7-Vijendar.Mukunda@amd.com Link: https://lore.kernel.org/r/20230321050901.115439-7-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: amd: add SoundWire manager interrupt handlingVijendar Mukunda2023-04-122-0/+127
| | | | | | | | | | | Add support for handling SoundWire manager interrupts. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Signed-off-by: Mastan Katragadda <Mastan.Katragadda@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/lkml/20230227154801.50319-6-Vijendar.Mukunda@amd.com Link: https://lore.kernel.org/r/20230321050901.115439-6-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: amd: enable build for AMD SoundWire manager driverVijendar Mukunda2023-04-122-0/+14
| | | | | | | | | | Enable build for SoundWire manager driver for AMD platforms. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/lkml/20230220100418.76754-5-Vijendar.Mukunda@amd.com Link: https://lore.kernel.org/r/20230321050901.115439-5-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: amd: register SoundWire manager dai opsVijendar Mukunda2023-04-122-0/+196
| | | | | | | | | | Register dai ops for SoundWire manager instances. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/lkml/20230227154801.50319-4-Vijendar.Mukunda@amd.com Link: https://lore.kernel.org/r/20230321050901.115439-4-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: amd: Add support for AMD Manager driverVijendar Mukunda2023-04-122-0/+905
| | | | | | | | | | | | | | | AMD ACP(v6.x) IP block has two SoundWire manager devices. Add support for - Manager driver probe & remove sequence - Helper functions to enable/disable interrupts, Initialize sdw manager, enable sdw pads - Manager driver sdw_master_ops & port_ops callbacks Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/lkml/20230310162554.699766-3-Vijendar.Mukunda@amd.com Link: https://lore.kernel.org/r/20230321050901.115439-3-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: export sdw_compute_slave_ports() functionVijendar Mukunda2023-04-122-9/+12
| | | | | | | | | | | | | Export sdw_compute_slave_ports() function to use it in another soundwire manager module. Move sdw_transport_data structure to bus header file to export sdw_compute_slave_ports() function. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/lkml/20230201165944.3169125-1-Vijendar.Mukunda@amd.com Link: https://lore.kernel.org/r/20230321050901.115439-2-Vijendar.Mukunda@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: stream: restore cumulative bus bandwidth when compute_params ↵Shuming Fan2023-04-121-1/+1
| | | | | | | | | | | | | | | | | | | callback failed The _sdw_prepare_stream function just returns the error code when compute_params callback failed. The cumulative bus bandwidth will keep the value and won't be decreased by sdw_deprepare_stream function. We should restore the value of cumulative bus bandwidth when compute_params callback failed. Signed-off-by: Shuming Fan <shumingf@realtek.com> Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230316013041.1008003-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: bandwidth allocation: Use hweight32() to calculate set bitsRichard Fitzgerald2023-04-122-12/+2
| | | | | | | | | | | | | | Replace the call to sdw_ch_mask_to_ch() with a call to hweight32(). sdw_ch_mask_to_ch() is counting the number of set bits. The hweight() family of functions already do this, and they have an advantage of using a bit-counting instruction if it is available on the target CPU. This also fixes a potential infinite loop bug in the implementation of sdw_ch_mask_to_ch(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230315145051.2299822-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: qcom: gracefully handle too many ports in DTKrzysztof Kozlowski2023-04-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | There are two issues related to the number of ports coming from Devicetree when exceeding in total QCOM_SDW_MAX_PORTS. Both lead to incorrect memory accesses: 1. With DTS having too big value of input or output ports, the driver, when copying port parameters from local/stack arrays into 'pconfig' array in 'struct qcom_swrm_ctrl', will iterate over their sizes. 2. If DTS also has too many parameters for these ports (e.g. qcom,ports-sinterval-low), the driver will overflow buffers on the stack when reading these properties from DTS. Add a sanity check so incorrect DTS will not cause kernel memory corruption. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230222144412.237832-2-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: qcom: define hardcoded version magic numbersKrzysztof Kozlowski2023-04-121-8/+9
| | | | | | | | | | | | Use a define instead of hard-coded register values for Soundwire hardware version number, because it is a bit easier to read and allows to drop explaining comment. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230222144412.237832-1-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: qcom: correct setting ignore bit on v1.5.1Krzysztof Kozlowski2023-04-121-1/+1
| | | | | | | | | | | | | According to the comment and to downstream sources, the SWRM_CONTINUE_EXEC_ON_CMD_IGNORE in SWRM_CMD_FIFO_CFG_ADDR register should be set for v1.5.1 and newer, so fix the >= operator. Fixes: 542d3491cdd7 ("soundwire: qcom: set continue execution flag for ignored commands") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230222140343.188691-1-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: cadence: change access to IP_MCP_CMD_BASEPierre-Louis Bossart2023-03-151-9/+9
| | | | | | | | | | | | | | | | | The latest Cadence IP moves MCP_CMD_BASE and MCP_CMD_RESP to the IP_MCP_CMD_BASE and IP_MCP_CMD_RESP registers located in different area and accessed with a fixed offset. Unlike other patches, the fields are not renamed to avoid a very invasive and low-value set of changes. For existing solutions, this is an iso-functionality change. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-17-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: cadence: split access to IP_MCP_CMDCTRL fieldsPierre-Louis Bossart2023-03-151-8/+8
| | | | | | | | | | | | | | | | The latest Cadence IP splits the MCP_CMDCTRL fields in two registers: MCP_CMDCTRL and IP_MCP_CMDCTRL. Rename the relevant fields and change the access methods used for those fields. In practice we only use the Parity error insertion in IP_CMD_CTRL. For existing solutions, this is an iso-functionality change. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-16-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: cadence: split access to IP_MCP_CONTROL fieldsPierre-Louis Bossart2023-03-151-16/+25
| | | | | | | | | | | | | | The latest Cadence IP splits the MCP_CONTROL fields in two registers: MCP_CONTROL and IP_MCP_CONTROL. Rename the relevant fields and change the access methods used for those fields. For existing solutions, this is an iso-functionality change. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-15-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: cadence: split access to IP_MCP_CONFIG fieldsPierre-Louis Bossart2023-03-151-20/+27
| | | | | | | | | | | | | | The latest Cadence IP splits the MCP_CONFIG fields in two registers: MCP_CONFIG and IP_MCP_CONFIG. Rename the relevant fields and change the access methods used for those fields. For existing solutions, this is an iso-functionality change. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-14-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: cadence: add helpers to access IP_MCP registersPierre-Louis Bossart2023-03-152-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | The latest Cadence IP splits some of the existing registers into two, separated by a fixed offset. The bitfields themselves remain at the same position, so we can use new helpers to dynamically add the fixed offset. For example, the existing MCP_CONFIG is now split in two with MCP_CONFIG and IP_MCP_CONFIG (the naming comes directly from the design document). This patch adds helpers to access registers with the IP_ prefix. The addition of the 'ip' prefix for helpers, registers and bitfields is intentional to help reviewers spot any mistake. For existing solutions, the offset is exactly zero so there's no functional change - the MCP_CONFIG and IP_MCP_CONFIG are aliased to the same address. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-13-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: cadence: remove CDNS_MCP_CONFIG_SSPMODPierre-Louis Bossart2023-03-151-1/+0
| | | | | | | | | | | This field is not used, and its definition is not aligned with the hardware specification. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-12-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: move bank switch routine to common intel_bus_common.cPierre-Louis Bossart2023-03-153-49/+53
| | | | | | | | | | | No functionality change, just moving the routines to a common file so that they can be used for new hardware. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-11-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: add abstraction for cmdsync checkPierre-Louis Bossart2023-03-152-11/+20
| | | | | | | | | | | | If we add one more callback, we can have common bank switch sequences between old and new hardware: the only difference is where the CMDSYNC register is located. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-10-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: move bus common sequences to different filePierre-Louis Bossart2023-03-154-200/+219
| | | | | | | | | | | | | | | | | Now that the bus start/stop/clock_stop sequences use the ops, we can move them to a different file to reuse them. Note that we could in theory remove the abstraction for all those sequences and directly call the functions in intel_auxdevice.c. To allow for more flexibility and have means to special-case new platforms, we decided to keep the abstraction. If in time it becomes clear there is no benefit the abstraction will be simplified. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-9-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: use indirection before moving bus start/stop sequencesPierre-Louis Bossart2023-03-151-2/+2
| | | | | | | | | | | There was no benefit to using the existing abstraction, but since we are going to move the code make sure we do use the ops. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-8-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: add sync_arm/sync_go to opsPierre-Louis Bossart2023-03-152-6/+30
| | | | | | | | | | | | The bus start/stop sequences can be reused between platforms if we add a couple of new callbacks. In following patches the code will be moved to a shared file. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-7-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: simplify sync_go sequencePierre-Louis Bossart2023-03-151-7/+2
| | | | | | | | | | | | | | | | | | In the existing code, the SHIM_SYNC::SYNC_GO bit is set, and the code waits for it to return to zero. That second wait part is just wrong: the SYNC_GO bit is *write-only* so there's no way to know if it's cleared by hardware. The code works because the value for a read-only bit is zero, but that's really just luck. Simplify the sequence to a plain read-modify-write. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-6-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: remove useless abstractionPierre-Louis Bossart2023-03-151-8/+1
| | | | | | | | | | | PDM is supported in the hardware but never enabled: there are no known PDM-based devices. We can directly call the PCM helper. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-5-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: remove PDI-level restrictions on rates and formatsPierre-Louis Bossart2023-03-151-4/+0
| | | | | | | | | | | | This is not relevant and not aligned with hardware definitions. In addition, we've tested higher resolution formats so this is ignored at a higher level. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-4-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: remove stale/misleading commentPierre-Louis Bossart2023-03-151-1/+0
| | | | | | | | | | | The PDIs don't really have a notion of rates and formats, only channels are relevant. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: intel: move common definitions to header filePierre-Louis Bossart2023-03-152-32/+29
| | | | | | | | | | Prepare for reused for addition of new hardware Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314015410.487311-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* soundwire: dmi-quirks: add remapping for Intel 'Rooks County' NUC M15Eugene Huang2023-03-151-0/+25
| | | | | | | | | | | | | Same DSDT problem as the HP Omen 16-k0005TX, except rt1316 amp is on link2. Link: https://github.com/thesofproject/linux/issues/4088 Signed-off-by: Eugene Huang <eugene.huang99@gmail.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230314090618.498716-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
* Merge tag 'soundwire-6.3-rc1' of ↵Linus Torvalds2023-02-259-146/+103
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire Pull soundwire updates from Vinod Koul: "This is a small update which features a bit of core changes and driver updates in Intel and cadence driver. Core: - sdw_transfer_defer() API change to drop an argument - Reset page address rework - Export sdw_nwrite_no_pm and sdw_nread_no_pm APIs Drivers: - Cadence and related intel driver updates for FIFO handling and low level msg transfers" * tag 'soundwire-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: soundwire: cadence: further simplify low-level xfer_msg_defer() callback soundwire: cadence: use directly bus sdw_defer structure soundwire: bus: remove sdw_defer argument in sdw_transfer_defer() soundwire: stream: use consistent pattern for freeing buffers soundwire: bus: Remove unused reset_page_addr() callback soundwire: bus: Don't zero page registers after every transaction soundwire: bus_type: Avoid lockdep assert in sdw_drv_probe() soundwire: stream: Move remaining register accesses over to no_pm soundwire: debugfs: Switch to sdw_read_no_pm soundwire: Provide build stubs for common functions soundwire: bus: export sdw_nwrite_no_pm and sdw_nread_no_pm functions soundwire: cadence: remove unused sdw_cdns_master_ops declaration soundwire: enable optional clock registers for SoundWire 1.2 devices ASoC/soundwire: remove is_sdca boolean property soundwire: cadence: Drain the RX FIFO after an IO timeout soundwire: cadence: Remove wasted space in response_buf soundwire: cadence: Don't overflow the command FIFOs soundwire: intel: remove DAI startup/shutdown
| * soundwire: cadence: further simplify low-level xfer_msg_defer() callbackPierre-Louis Bossart2023-01-313-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | The message pointer is already stored in the bus->defer structure, not need to pass it as an argument. Suggested-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230119073211.85979-5-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * soundwire: cadence: use directly bus sdw_defer structurePierre-Louis Bossart2023-01-313-14/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Copying the bus sdw_defer structure into the Cadence internals leads to using stale pointers and kernel oopses on errors. It's just simpler and safer to use the bus sdw_defer structure directly. Link: https://github.com/thesofproject/linux/issues/4056 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230119073211.85979-4-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * soundwire: bus: remove sdw_defer argument in sdw_transfer_defer()Pierre-Louis Bossart2023-01-313-11/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no point in passing an argument that is a pointer to a bus member. We can directly get the member and do an indirection when needed. This is a first step before simplifying the hardware-specific callbacks further. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230119073211.85979-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * soundwire: stream: use consistent pattern for freeing buffersPierre-Louis Bossart2023-01-311-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The code should free the message buffer used for data, the message structure used for control and assign the latter to NULL. The last part is missing for multi-link cases, and the order is inconsistent for single-link cases. Link: https://github.com/thesofproject/linux/issues/4056 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230119073211.85979-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * soundwire: bus: Remove unused reset_page_addr() callbackRichard Fitzgerald2023-01-313-18/+0
| | | | | | | | | | | | | | | | | | | | | | A previous patch removed unnecessary zeroing of the page registers after a paged transaction, so now the reset_page_addr callback is unused and can be removed. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230123164949.245898-3-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * soundwire: bus: Don't zero page registers after every transactionRichard Fitzgerald2023-01-311-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Zeroing the page registers at the end of every paged transaction is just overhead (40% overhead on a 1-register access, 25% on a 4-register transaction). According to the spec a peripheral that supports paging should only use the values in the page registers if the address is paged (address bit 15 set). The core SoundWire code always writes the page registers at the start of a paged transaction so there will never be a transaction that uses the stale values from a previous paged transaction. For peripherals that need large amounts of data to be transferred, for example firmware or filter coefficients, the overhead of page register zeroing can become quite significant. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230123164949.245898-2-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * soundwire: bus_type: Avoid lockdep assert in sdw_drv_probe()Richard Fitzgerald2023-01-311-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't hold sdw_dev_lock while calling the peripheral driver probe() and remove() callbacks. Holding sdw_dev_lock around the probe() and remove() calls causes a theoretical mutex inversion which lockdep will assert on. During probe() the sdw_dev_lock mutex is taken first and then ASoC/ALSA locks are taken by the probe() implementation. During normal operation ASoC can take its locks and then trigger a runtime resume of the component. The SoundWire resume will then take sdw_dev_lock. This is the reverse order compared to probe(). It's not necessary to hold sdw_dev_lock when calling the probe() and remove(), it is only used to prevent the bus core calling the driver callbacks if there isn't a driver or the driver is removing. All calls to the driver callbacks are guarded by the 'probed' flag. So if sdw_dev_lock is held while setting and clearing the 'probed' flag this is sufficient to guarantee the safety of callback functions. Removing the mutex from around the call to probe() means that it is now possible for a bus event (PING response) to be handled in parallel with the probe(). But sdw_bus_probe() already has handling for this by calling the device update_status() after the probe() has completed. Example lockdep assert: [ 46.098514] ====================================================== [ 46.104736] WARNING: possible circular locking dependency detected [ 46.110961] 6.1.0-rc4-jamerson #1 Tainted: G E [ 46.116842] ------------------------------------------------------ [ 46.123063] mpg123/1130 is trying to acquire lock: [ 46.127883] ffff8b445031fb80 (&slave->sdw_dev_lock){+.+.}-{3:3}, at: sdw_update_slave_status+0x26/0x70 [ 46.137225] but task is already holding lock: [ 46.143074] ffffffffc1455310 (&card->pcm_mutex){+.+.}-{3:3}, at: dpcm_fe_dai_open+0x49/0x830 [ 46.151536] which lock already depends on the new lock.[ 46.159732] the existing dependency chain (in reverse order) is: [ 46.167231] -> #4 (&card->pcm_mutex){+.+.}-{3:3}: [ 46.173428] __mutex_lock+0x94/0x920 [ 46.177542] snd_soc_dpcm_runtime_update+0x2e/0x100 [ 46.182958] snd_soc_dapm_put_enum_double+0x1c2/0x200 [ 46.188548] snd_ctl_elem_write+0x10c/0x1d0 [ 46.193268] snd_ctl_ioctl+0x126/0x850 [ 46.197556] __x64_sys_ioctl+0x87/0xc0 [ 46.201845] do_syscall_64+0x38/0x90 [ 46.205959] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 46.211553] -> #3 (&card->controls_rwsem){++++}-{3:3}: [ 46.218188] down_write+0x2b/0xd0 [ 46.222038] snd_ctl_add_replace+0x39/0xb0 [ 46.226672] snd_soc_add_controls+0x53/0x80 [ 46.231393] soc_probe_component+0x1e4/0x2a0 [ 46.236202] snd_soc_bind_card+0x51a/0xc80 [ 46.240836] devm_snd_soc_register_card+0x43/0x90 [ 46.246079] mc_probe+0x982/0xfe0 [snd_soc_sof_sdw] [ 46.251500] platform_probe+0x3c/0xa0 [ 46.255700] really_probe+0xde/0x390 [ 46.259814] __driver_probe_device+0x78/0x180 [ 46.264710] driver_probe_device+0x1e/0x90 [ 46.269347] __driver_attach+0x9f/0x1f0 [ 46.273721] bus_for_each_dev+0x78/0xc0 [ 46.278098] bus_add_driver+0x1ac/0x200 [ 46.282473] driver_register+0x8f/0xf0 [ 46.286759] do_one_initcall+0x58/0x310 [ 46.291136] do_init_module+0x4c/0x1f0 [ 46.295422] __do_sys_finit_module+0xb4/0x130 [ 46.300321] do_syscall_64+0x38/0x90 [ 46.304434] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 46.310027] -> #2 (&card->mutex){+.+.}-{3:3}: [ 46.315883] __mutex_lock+0x94/0x920 [ 46.320000] snd_soc_bind_card+0x3e/0xc80 [ 46.324551] devm_snd_soc_register_card+0x43/0x90 [ 46.329798] mc_probe+0x982/0xfe0 [snd_soc_sof_sdw] [ 46.335219] platform_probe+0x3c/0xa0 [ 46.339420] really_probe+0xde/0x390 [ 46.343532] __driver_probe_device+0x78/0x180 [ 46.348430] driver_probe_device+0x1e/0x90 [ 46.353065] __driver_attach+0x9f/0x1f0 [ 46.357437] bus_for_each_dev+0x78/0xc0 [ 46.361812] bus_add_driver+0x1ac/0x200 [ 46.366716] driver_register+0x8f/0xf0 [ 46.371528] do_one_initcall+0x58/0x310 [ 46.376424] do_init_module+0x4c/0x1f0 [ 46.381239] __do_sys_finit_module+0xb4/0x130 [ 46.386665] do_syscall_64+0x38/0x90 [ 46.391299] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 46.397416] -> #1 (client_mutex){+.+.}-{3:3}: [ 46.404307] __mutex_lock+0x94/0x920 [ 46.408941] snd_soc_add_component+0x24/0x2c0 [ 46.414345] devm_snd_soc_register_component+0x54/0xa0 [ 46.420522] cs35l56_common_probe+0x280/0x370 [snd_soc_cs35l56] [ 46.427487] cs35l56_sdw_probe+0xf4/0x170 [snd_soc_cs35l56_sdw] [ 46.434442] sdw_drv_probe+0x80/0x1a0 [ 46.439136] really_probe+0xde/0x390 [ 46.443738] __driver_probe_device+0x78/0x180 [ 46.449120] driver_probe_device+0x1e/0x90 [ 46.454247] __driver_attach+0x9f/0x1f0 [ 46.459106] bus_for_each_dev+0x78/0xc0 [ 46.463971] bus_add_driver+0x1ac/0x200 [ 46.468825] driver_register+0x8f/0xf0 [ 46.473592] do_one_initcall+0x58/0x310 [ 46.478441] do_init_module+0x4c/0x1f0 [ 46.483202] __do_sys_finit_module+0xb4/0x130 [ 46.488572] do_syscall_64+0x38/0x90 [ 46.493158] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 46.499229] -> #0 (&slave->sdw_dev_lock){+.+.}-{3:3}: [ 46.506737] __lock_acquire+0x1121/0x1df0 [ 46.511765] lock_acquire+0xd5/0x300 [ 46.516360] __mutex_lock+0x94/0x920 [ 46.520949] sdw_update_slave_status+0x26/0x70 [ 46.526409] sdw_clear_slave_status+0xd8/0xe0 [ 46.531783] intel_resume_runtime+0x139/0x2a0 [ 46.537155] __rpm_callback+0x41/0x120 [ 46.541919] rpm_callback+0x5d/0x70 [ 46.546422] rpm_resume+0x531/0x7e0 [ 46.550920] __pm_runtime_resume+0x4a/0x80 [ 46.556024] snd_soc_pcm_component_pm_runtime_get+0x2f/0xc0 [ 46.562611] __soc_pcm_open+0x62/0x520 [ 46.567375] dpcm_be_dai_startup+0x116/0x210 [ 46.572661] dpcm_fe_dai_open+0xf7/0x830 [ 46.577597] snd_pcm_open_substream+0x54a/0x8b0 [ 46.583145] snd_pcm_open.part.0+0xdc/0x200 [ 46.588341] snd_pcm_playback_open+0x51/0x80 [ 46.593625] chrdev_open+0xc0/0x250 [ 46.598129] do_dentry_open+0x15f/0x430 [ 46.602981] path_openat+0x75e/0xa80 [ 46.607575] do_filp_open+0xb2/0x160 [ 46.612162] do_sys_openat2+0x9a/0x160 [ 46.616922] __x64_sys_openat+0x53/0xa0 [ 46.621767] do_syscall_64+0x38/0x90 [ 46.626352] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 46.632414] other info that might help us debug this:[ 46.641862] Chain exists of: &slave->sdw_dev_lock --> &card->controls_rwsem --> &card->pcm_mutex[ 46.655145] Possible unsafe locking scenario:[ 46.662048] CPU0 CPU1 [ 46.667080] ---- ---- [ 46.672108] lock(&card->pcm_mutex); [ 46.676267] lock(&card->controls_rwsem); [ 46.683382] lock(&card->pcm_mutex); [ 46.690063] lock(&slave->sdw_dev_lock); [ 46.694574] *** DEADLOCK ***[ 46.701942] 2 locks held by mpg123/1130: [ 46.706356] #0: ffff8b4457b22b90 (&pcm->open_mutex){+.+.}-{3:3}, at: snd_pcm_open.part.0+0xc9/0x200 [ 46.715999] #1: ffffffffc1455310 (&card->pcm_mutex){+.+.}-{3:3}, at: dpcm_fe_dai_open+0x49/0x830 [ 46.725390] stack backtrace: [ 46.730752] CPU: 0 PID: 1130 Comm: mpg123 Tainted: G E 6.1.0-rc4-jamerson #1 [ 46.739703] Hardware name: AAEON UP-WHL01/UP-WHL01, BIOS UPW1AM19 11/10/2020 [ 46.747270] Call Trace: [ 46.750239] <TASK> [ 46.752857] dump_stack_lvl+0x56/0x73 [ 46.757045] check_noncircular+0x102/0x120 [ 46.761664] __lock_acquire+0x1121/0x1df0 [ 46.766197] lock_acquire+0xd5/0x300 [ 46.770292] ? sdw_update_slave_status+0x26/0x70 [ 46.775432] ? lock_is_held_type+0xe2/0x140 [ 46.780143] __mutex_lock+0x94/0x920 [ 46.784241] ? sdw_update_slave_status+0x26/0x70 [ 46.789387] ? find_held_lock+0x2b/0x80 [ 46.793750] ? sdw_update_slave_status+0x26/0x70 [ 46.798894] ? lock_release+0x147/0x2f0 [ 46.803262] ? lockdep_init_map_type+0x47/0x250 [ 46.808315] ? sdw_update_slave_status+0x26/0x70 [ 46.813456] sdw_update_slave_status+0x26/0x70 [ 46.818422] sdw_clear_slave_status+0xd8/0xe0 [ 46.823302] ? pm_generic_runtime_suspend+0x30/0x30 [ 46.828706] intel_resume_runtime+0x139/0x2a0 [ 46.833583] ? _raw_spin_unlock_irq+0x24/0x50 [ 46.838462] ? pm_generic_runtime_suspend+0x30/0x30 [ 46.843866] __rpm_callback+0x41/0x120 [ 46.848142] ? pm_generic_runtime_suspend+0x30/0x30 [ 46.853550] rpm_callback+0x5d/0x70 [ 46.857568] rpm_resume+0x531/0x7e0 [ 46.861578] ? _raw_spin_lock_irqsave+0x62/0x70 [ 46.866634] __pm_runtime_resume+0x4a/0x80 [ 46.871258] snd_soc_pcm_component_pm_runtime_get+0x2f/0xc0 [ 46.877358] __soc_pcm_open+0x62/0x520 [ 46.881634] ? dpcm_add_paths.isra.0+0x35d/0x4c0 [ 46.886784] dpcm_be_dai_startup+0x116/0x210 [ 46.891592] dpcm_fe_dai_open+0xf7/0x830 [ 46.896046] ? debug_mutex_init+0x33/0x50 [ 46.900591] snd_pcm_open_substream+0x54a/0x8b0 [ 46.905658] snd_pcm_open.part.0+0xdc/0x200 [ 46.910376] ? wake_up_q+0x90/0x90 [ 46.914312] snd_pcm_playback_open+0x51/0x80 [ 46.919118] chrdev_open+0xc0/0x250 [ 46.923147] ? cdev_device_add+0x90/0x90 [ 46.927608] do_dentry_open+0x15f/0x430 [ 46.931976] path_openat+0x75e/0xa80 [ 46.936086] do_filp_open+0xb2/0x160 [ 46.940194] ? lock_release+0x147/0x2f0 [ 46.944563] ? _raw_spin_unlock+0x29/0x50 [ 46.949101] do_sys_openat2+0x9a/0x160 [ 46.953377] __x64_sys_openat+0x53/0xa0 [ 46.957733] do_syscall_64+0x38/0x90 [ 46.961829] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 46.967402] RIP: 0033:0x7fa6397ccd3b [ 46.971506] Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00 00 00 85 c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 91 00 00 00 48 8b 4c 24 28 64 48 33 0c 25 [ 46.991413] RSP: 002b:00007fff838e8990 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 [ 46.999580] RAX: ffffffffffffffda RBX: 0000000000080802 RCX: 00007fa6397ccd3b [ 47.007311] RDX: 0000000000080802 RSI: 00007fff838e8b50 RDI: 00000000ffffff9c [ 47.015047] RBP: 00007fff838e8b50 R08: 0000000000000000 R09: 0000000000000011 [ 47.022787] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000080802 [ 47.030539] R13: 0000000000000004 R14: 0000000000000000 R15: 00007fff838e8b50 [ 47.038289] </TASK> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230123172520.339367-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
| * soundwire: stream: Move remaining register accesses over to no_pmCharles Keepax2023-01-092-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no need to play with the runtime reference everytime a register is accessed. All the remaining "pm" style register accesses trace back to 4 functions: sdw_prepare_stream sdw_deprepare_stream sdw_enable_stream sdw_disable_stream Any sensible implementation will need to hold a runtime reference across all those functions, it makes no sense to be allowing the device/bus to suspend whilst streams are being prepared/enabled. And certainly in the case of the all existing users, they all call these functions from hw_params/prepare/trigger/hw_free callbacks in ALSA, which will have already runtime resumed all the audio devices associated during the open callback. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20221125142028.1118618-5-ckeepax@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-21 15:53:58 +0100