- 06 Apr, 2021 8 commits
-
-
Bard Liao authored
intel_link_probe() could return error and dev_get_drvdata() will return null in such case. So we have to test link->cdns after link->cdns = dev_get_drvdata(&ldev->auxdev.dev); Otherwise, we will meet the "kernel NULL pointer dereference" error. Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
Rander Wang <rander.wang@intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210406010101.11442-1-yung-chuan.liao@linux.intel.comSigned-off-by:
Vinod Koul <vkoul@kernel.org>
-
Srinivas Kandagatla authored
Looks like return from reg_write is set but not checked. Fix this by adding error return path. Reported-by:
coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1503591 ("UNUSED_VALUE") Fixes: 128eaf93 ("soundwire: qcom: add support to missing transport params") Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210401091502.15825-1-srinivas.kandagatla@linaro.orgSigned-off-by:
-
Srinivas Kandagatla authored
Internally used portconfig array for storing port bandwidth params starts from offset zero. However port zero is not really used and we also copy the bus parameters to offset zero. So basically we endup with a code which has to subtract 1 from port number to get to port parameters. This is bit confusing to the reader so, make this bit more obvious by only copying the parameters to offset 1 instead of zero. This will avoid doing -1 every time when we try to get port params. Similar thing has been recently done with din/dout_port_mask. Signed-off-by:
-
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 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:
-
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:
Keyon Jie <yang.jie@intel.com> Reviewed-by:
Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-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 1 commit
-
-
Bard Liao authored
Now that we have declarations and bus support, add quirks for Intel platforms. Co-developed-by:
-
