soundwire: add multi-lane support
The first 2 commits are from https://github.com/thesofproject/linux/pull/4704.
This PR adds SoundWire multi-lane support.
Hmm, the CI test Failure on TGLU_RVP_SDW-ipc4 is because that 2 1308 amps are on the same sdw link, and 1 controller data port maps to 2 peripheral data ports. But I assume that controller data port and peripheral data port is 1:1 mapping. I need to think about how to handle this case.
looks good except for the first patch missing your sign-off @bardliao
Updated to
Co-developed-by: Chao Song <[email protected]>
Signed-off-by: Chao Song <[email protected]>
Signed-off-by: Bard Liao <[email protected]>
@plbossart @ranj063 @ujfalusi I just found an issue when I tested with dynamic sdw bus clock. We need to clear p_rt->ch_mask when deprepare. Otherwise, sdw_compute_group_params() will still count the port bandwidth which is already stop when it is called in deprepare. And it will return error when we stop a stream and reduce the sdw clock. The same issue happens in the existing code, too. But we won't meet the issue because currently the sdw clock will never change.
@plbossart @ranj063 @ujfalusi I just found an issue when I tested with dynamic sdw bus clock. We need to clear
p_rt->ch_maskwhen deprepare. Otherwise, sdw_compute_group_params() will still count the port bandwidth which is already stop when it is called in deprepare. And it will return error when we stop a stream and reduce the sdw clock. The same issue happens in the existing code, too. But we won't meet the issue because currently the sdw clock will never change.
It will impact the multi-lane support. I need to think more about it.
@plbossart @ranj063 @ujfalusi I just found an issue when I tested with dynamic sdw bus clock. We need to clear
p_rt->ch_maskwhen deprepare. Otherwise, sdw_compute_group_params() will still count the port bandwidth which is already stop when it is called in deprepare. And it will return error when we stop a stream and reduce the sdw clock. The same issue happens in the existing code, too. But we won't meet the issue because currently the sdw clock will never change.It will impact the multi-lane support. I need to think more about it.
@bardliao are you saying this PR is not ready for merging then? Also, what is the plan for testing multilane? I understand you have tested this locally but do we need to add tests to our CI also?
@plbossart @ranj063 @ujfalusi I just found an issue when I tested with dynamic sdw bus clock. We need to clear
p_rt->ch_maskwhen deprepare. Otherwise, sdw_compute_group_params() will still count the port bandwidth which is already stop when it is called in deprepare. And it will return error when we stop a stream and reduce the sdw clock. The same issue happens in the existing code, too. But we won't meet the issue because currently the sdw clock will never change.It will impact the multi-lane support. I need to think more about it.
@bardliao are you saying this PR is not ready for merging then? Also, what is the plan for testing multilane? I understand you have tested this locally but do we need to add tests to our CI also?
After 1 and half day's investigation, I decide to roll back to the reviewed/approved and full tested version. I.e. remove the set p_rt->ch_mask = 0 in deprepare change. I will continue debug the issue when enabling dynamic sdw clock change. But in the meantime, we can merge this if you agree. @ranj063 @plbossart @ujfalusi.
And yes, we need to setup a device to test multilane in CI. We will need a codec that can support multilane like rt722, rt712-vb
change: remove duplicated trace.