- 06 Apr, 2021 5 commits
-
-
Srinivas Kandagatla authored
If we write registers very fast we can endup in a situation where some of the writes will be dropped without any notice. So wait for the fifo space to be available before reading/writing the soundwire registers. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210401090058.24041-1-srinivas.kandagatla@linaro.orgSigned-off-by:
Vinod Koul <vkoul@kernel.org>
-
Srinivas Kandagatla authored
SoundWire device ports are statically mapped to Controller ports during design. Add support to read these from SoundWire devices. This controller uses static port map info to setup bandwidth parameters for those ports. A generic port allocation is not possible in this cases! Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210315165650.13392-4-srinivas.kandagatla@linaro.orgSigned-off-by:
-
Srinivas Kandagatla authored
currently the internal bitmask used for allocating ports starts with offset 0. This is bit confusing as data port numbers on Qualcomm controller are valid from 1 to 14. So adjust this bit mask accordingly, this will also help while adding static port map support. Signed-off-by:
-
Srinivas Kandagatla authored
Some of the SoundWire device ports are statically mapped to Controller ports during design, however there is no way to expose this information to the controller. Controllers like Qualcomm ones use this info to setup static bandwidth parameters for those ports. A generic port allocation is not possible in this cases! So this patch adds a new member m_port_map to struct sdw_slave to expose this static map. Signed-off-by:
-
Rander Wang authored
When stream config is failed, master runtime will release all slave runtime in the slave_rt_list, but slave runtime is not added to the list at this time. This patch frees slave runtime in the config error path to fix the memory leak. Fixes: 89e59053 ("soundwire: Add support for SoundWire stream management") Signed-off-by:
Rander Wang <rander.wang@intel.com> Reviewed-by:
Keyon Jie <yang.jie@intel.com> Reviewed-by:
Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20210331004610.12242-1-yung-chuan.liao@linux.intel.comSigned-off-by:
-
- 01 Apr, 2021 1 commit
-
-
Vinod Koul authored
We get warning of using a unsigned variable being compared to less than zero. The comparison is correct as it checks for errors from previous call to qcom_swrm_get_alert_slave_dev_num(), so we should use a signed variable here. While at it, drop the superfluous initialization as well drivers/soundwire/qcom.c: qcom_swrm_irq_handler() warn: impossible condition '(devnum < 0) => (0-255 < 0)' Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210331155520.2987823-1-vkoul@kernel.orgSigned-off-by:
-
- 30 Mar, 2021 25 commits
-
-
Srinivas Kandagatla authored
Signed-off-by:
-
Srinivas Kandagatla authored
Qualcomm SoundWire controller supports Auto Enumeration of the devices within the IP. This patch enables support for this feature. Signed-off-by:
-
Srinivas Kandagatla authored
Exporting these three functions makes sense as it can be used by other controllers like Qualcomm during auto-enumeration! Reported-by:
-
Srinivas Kandagatla authored
Add support to new interrupts which includes reporting some of the error interrupts and adding support to SLAVE pending interrupt! This patch also changes the interrupt handler behaviour on handling any pending interrupts by checking it before returning out of irq handler. Signed-off-by:
-
Srinivas Kandagatla authored
In the existing code every soundwire register read and register write are kinda blocked. Each of these are using a special command id that generates interrupt after it successfully finishes. This is really overhead, limiting and not really necessary unless we are doing something special. We can simply read/write the fifo that should also give exactly what we need! This will also allow to read/write registers in interrupt context, which was not possible with the special command approach. With previous approach number of interrupts generated after enumeration are around 130: $ cat /proc/interrupts | grep soundwire 21: 130 0 0 0 0 0 0 0 GICv3 234 Edge soundwire after this patch they are just 3 interrupts $ cat /proc/interrupts | grep soundwire 21: 3 0 0 0 0 0 0 0 GICv3 234 Edge soundwire This has significantly not only reduced interrupting CPU during enumeration but also during streaming! Signed-off-by:
-
Srinivas Kandagatla authored
Start the clock during initialization, doing this explicitly will add more clarity when we are adding clock stop feature. Signed-off-by:
-
Srinivas Kandagatla authored
version 1.5.1 and higher IPs of this controller required to set continue execution on ignored command flag. This patch sets this flag. Signed-off-by:
-
Srinivas Kandagatla authored
Some of the transport parameters derived from device tree are not fully parsed by the driver. This patch adds support to parse those missing parameters. Signed-off-by:
-
Srinivas Kandagatla authored
Some of the parameters for data ports are not applicable or not implemented in IP. So mark them as invalid/not applicable in DT so that controller is aware of this. Add comment to these bindings to provide more clarity on the values! Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Pierre-Louis Bossart authored
We sometimes see COMMAND_IGNORED responses during the clock stop sequence. It turns out we already have information if devices are present on a link, so we should only prepare those when they are attached. In addition, even when COMMAND_IGNORED are received, we should still proceed with the clock stop. The device will not be prepared but that's not a problem. The only case where the clock stop will fail is if the Cadence IP reports an error (including a timeout), or if the devices throw a COMMAND_FAILED response. BugLink: https://github.com/thesofproject/linux/issues/2621Signed-off-by:
-
Pierre-Louis Bossart authored
The existing code makes no sense, we multiply a channel number by zero (SDW_BLK_GRP_CNT_1), and the result is used to configure the block packing mode. Sampling grouping and channel packing are two separate concepts in SoundWire. In addition, the bandwidth allocation allocates a vertical slice for each stream, which makes the use of the PER_CHANNEL packing mode irrelevant. Let's use the proper definition for block packing mode (PER_PORT). This change has no functional impact though since the net result is the same configuration of the DPN_BlockCtrl3 register, when implemented. Reported-by:
-
Pierre-Louis Bossart authored
For some reason we don't have an enum for this concept. Add definitions following Table 102 of the SoundWire 1.2 specification. Signed-off-by:
-
Srinivas Kandagatla authored
found flag is used to indicate SoundWire devices that are both enumerated on the bus and available in the device list. However this flag is not reset correctly after one iteration, This could miss some of the devices that are enumerated on the bus but not in device list. So reset this correctly to fix this issue! Fixes: d52d7a1b ("soundwire: Add Slave status handling helpers") Signed-off-by:
-
Pierre-Louis Bossart authored
v5.12-rc1 flags new warnings with make W=1, fix missing or broken function descriptors. drivers/soundwire/cadence_master.c:914: warning: expecting prototype for To update slave status in a work since we will need to handle(). Prototype was for cdns_update_slave_status_work() instead drivers/soundwire/cadence_master.c:976: warning: expecting prototype for sdw_cdns_enable_slave_interrupt(). Prototype was for cdns_enable_slave_interrupts() instead Signed-off-by:
-
Pierre-Louis Bossart authored
There is no need to assign a pointer to NULL if it's only used in a loop and assigned within that loop. Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
-
Pierre-Louis Bossart authored
Cppcheck complains about possible null pointer dereferences, but it's more like there are unnecessary initializations before walking through a list. Signed-off-by:
-
Pierre-Louis Bossart authored
Cppcheck complains: drivers/soundwire/qcom.c:773:6: style: Variable 'ret' is assigned a value that is never used. [unreadVariable] ret = of_property_read_u8_array(np, "qcom,ports-block-pack-mode", ^ The return value is checked for all other cases, not sure why it was missed here. Signed-off-by: -
Pierre-Louis Bossart authored
Cppcheck complains: drivers/soundwire/intel.c:564:15: style: Variable 'link_control' is assigned a value that is never used. [unreadVariable] link_control = intel_readl(shim, SDW_SHIM_LCTL); This looks like a leftover from a previous version, remove. Signed-off-by:
-
Pierre-Louis Bossart authored
Cppcheck complains about two possible null pointer dereferences, but it's more like there are unnecessary initializations before walking through a list. Signed-off-by:
-
Pierre-Louis Bossart authored
Cppcheck complains about a possible null pointer dereference, but it's more like there is an unnecessary initialization before walking through a list. Signed-off-by:
-
Pierre-Louis Bossart authored
We have multiple cases where we read/write SCP_INT registers, but the same error message in all cases. Add a distinct error message for each case to help debug. Reported-by:
Guennadi Liakhovetski <guennadi.liakhovetski@intel.com> Reviewed-by:
-
Pierre-Louis Bossart authored
There is no real reason to provide this information except for debug sessions, hence dev_dbg() is a better fit. Reported-by:
-
Pierre-Louis Bossart authored
We use different styles to check the return values of IO related routines. The majority of the cases use 'if (ret < 0)', align the remaining cases for consistency. Signed-off-by:
-
Pierre-Louis Bossart authored
In the existing code we may read a negative error value but still mask it and write it back. Make sure all reads are tested and errors not propagated further. Signed-off-by:
-
Pierre-Louis Bossart authored
None of the existing codec drivers set the sdw_driver.name, but instead set sdw_driver.driver.name. This leads to error messages such as [ 23.935355] rt700 sdw:2:25d:700:0: Probe of (null) failed: -19 We could remove this sdw_driver.name if it doesn't have any purpose. This patch only suggests using the proper indirection. Signed-off-by:
-
- 23 Mar, 2021 5 commits
-
-
Pierre-Louis Bossart authored
We fixed a lot of warnings in 2019 but the magic of copy-paste keeps adding new ones... Signed-off-by:
-
Pierre-Louis Bossart authored
We fixed a lot of warnings in 2019 but the magic of copy-paste keeps adding new ones... Signed-off-by:
-
Pierre-Louis Bossart authored
We fixed a lot of warnings in 2019 but the magic of copy-paste keeps adding new ones... Signed-off-by:
-
Pierre-Louis Bossart authored
We fixed a lot of warnings in 2019 but the magic of copy-paste keeps adding new ones... Signed-off-by:
-
Pierre-Louis Bossart authored
We fixed a lot of warnings in 2019 but the magic of copy-paste keeps adding new ones... Signed-off-by:
-
- 22 Mar, 2021 4 commits
-
-
Bard Liao authored
Now that we have declarations and bus support, add quirks for Intel platforms. Co-developed-by:
-
Bard Liao authored
Add optional interrupt status read/clear if the master quirks are set. In the case of the parity, the master quirk is only applied if the Slave doesn't already have a parity-related quirk. Co-developed-by:
-
Bard Liao authored
Currently quirks are only allowed for Slave devices. This patch describes the need for two quirks at the Master level. a) bus clash The SoundWire specification allows a Slave device to report a bus clash with the in-band interrupt mechanism when it detects a conflict while driving a bitSlot it owns. This can be a symptom of an electrical conflict or a programming error, and it's vital to detect reliably. Unfortunately, on some platforms, bus clashes are randomly reported by Slave devices after a bus reset, with an interrupt status set even before the bus clash interrupt is enabled. These initial spurious interrupts are not relevant and should optionally be filtered out, while leaving the interrupt mechanism enabled to detect 'true' issues. This patch suggests the addition of a Master level quirk to discard such interrupts. The quirk should in theory have been added at the Slave level, but since the problem was detected with different generations of Slave devices it's hard to point to a specific IP. The problem might also be board-dependent and hence dealing with a Master quirk is simpler. b) parity Additional tests on a new platform with the Maxim 98373 amplifier showed a rare case where the parity interrupt is also thrown on startup, at the same time as bus clashes. This issue only seems to happen infrequently and was only observed during suspend-resume stress tests while audio is streaming. We could make the problem go away by adding a Slave-level quirk, but there is no evidence that the issue is actually a Slave problem: the parity is provided by the Master, which could also set an invalid parity in corner cases. BugLink: https://github.com/thesofproject/linux/issues/2578 BugLink: https://github.com/thesofproject/linux/issues/2533Co-developed-by:
-
Pierre-Louis Bossart authored
We've been handling ACPI issues on early versions of the product with a local ACPI initrd override but now that we have the possibility of a kernel quirk let's get rid of the initrd override. This helps make sure that the kernel will support all versions of the BIOS, with or without updates. Co-developed-by:
-
