SoundWire: msg ignored during BTP transfer with pm_runtime enabled (dspless mode) #4784
Comments
|
This does NOT happen with an audio playback, only when resuming to do a BPT transfer. |
|
The main difference is that BPT resumes the PCI device but not the card. I don't know ASoC enough but I suspect there's some magic for jack detection coming from the card. |
|
forcing a pm_runtime resume manually works fine, it's as if the use of DP0 causes the issue. Humm, maybe it's the interrupt register that's shared with SDCA... |
|
[ 461.369199] soundwire_intel:intel_ace2x_bpt_send_async: soundwire_intel soundwire_intel.link.0: BPT Transfer start Sorry, I can't find the source code that prints the BPT Transfer start/wait/done. |
|
The BPT protocol uses DP0, but regular command use column0. In theory they are completely orthogonal, it's perfectly fine to send a read command while doing a BPT write. That said, there's obviously some level of interference. The code for BPT is in PR #4679 |
|
@shumingfan @bardliao I think the issue is on the codec side, I added the following diff diff --git a/sound/soc/codecs/rt711-sdca-sdw.c b/sound/soc/codecs/rt711-sdca-sdw.c
index 34a0d9e0ce39..55b351fa75cf 100644
--- a/sound/soc/codecs/rt711-sdca-sdw.c
+++ b/sound/soc/codecs/rt711-sdca-sdw.c
@@ -328,9 +328,17 @@ static int rt711_sdca_interrupt_callback(struct sdw_slave *slave,
"%s scp_sdca_stat1=0x%x, scp_sdca_stat2=0x%x\n", __func__,
rt711->scp_sdca_stat1, rt711->scp_sdca_stat2);
- if (status->sdca_cascade && !rt711->disable_irq)
+ if (status->sdca_cascade && !rt711->disable_irq) {
+
+ dev_warn(&slave->dev,
+ "%s PLB before jack_detect_work\n", __func__);
+
mod_delayed_work(system_power_efficient_wq,
- &rt711->jack_detect_work, msecs_to_jiffies(30));
+ &rt711->jack_detect_work, msecs_to_jiffies(100));
+
+ dev_warn(&slave->dev,
+ "%s PLB after jack_detect_work\n", __func__);
+ }
mutex_unlock(&rt711->disable_irq_lock);
diff --git a/sound/soc/codecs/rt711-sdca.c b/sound/soc/codecs/rt711-sdca.c
index 447154cb6010..3bf8d1027967 100644
--- a/sound/soc/codecs/rt711-sdca.c
+++ b/sound/soc/codecs/rt711-sdca.c
@@ -248,12 +248,35 @@ static int rt711_sdca_headset_detect(struct rt711_sdca_priv *rt711)
unsigned int det_mode;
int ret;
+ dev_warn(&rt711->slave->dev,
+ "%s start hw_init %d\n", __func__, rt711->hw_init);
+
+ {
+ int int1;
+ int val;
+
+ int1 = sdw_read_no_pm(rt711->slave, SDW_SCP_SDCA_INT1);
+
+ dev_warn(&rt711->slave->dev,
+ "%s int1 read %d\n", __func__, int1);
+
+ val = sdw_read_no_pm(rt711->slave,
+ SDW_SDCA_CTL(FUNC_NUM_JACK_CODEC,
+ RT711_SDCA_ENT_GE49,
+ RT711_SDCA_CTL_DETECTED_MODE, 0));
+ dev_warn(&rt711->slave->dev,
+ "%s read %d\n", __func__, val);
+ }
So basically doing a basic read works fine, but accessing a register inside the SDCA function fails. Could this be a first example of the 'Function Busy" where we need to repeat the reads if the function cannot provide the results? |
|
@shuming this happens when doing a BRA transfer to address 0x44010000, so wondering if a read to the SDCA function space can happen while a BRA transfer is on-going. |
|
@plbossart I will check this issue with our hardware engineer. If any results, I will feedback to you. |
|
@plbossart Could you confirm whether the MIPI-defined registers 0x48/0x49 (SCP_AddrPage1/2) are correct before the control word of SDCA control reads? |
|
@shumingfan the calibration works when there is no BPT/BRA transfer, so my guess is that the registers are correct. The problem occurs when we resume the device for a BPT/BRA transfer, at some point the calibration kicks in and that's where we get a failed read. I will add a trace of when we change the SCP_Addr registers. |
|
@shumingfan here's the log you wanted. addr_page1 0x80 and addr_page2 0xc0, no issue |
|
@plbossart Hmm..it is hard to read back 0x48/0x49 registers before the last read command. |
|
@shumingfan the BPT/BRA stream uses columns 1..3, it's completely independent from the command word. Again the issue is Such an error can only come if
My money is on 3) or 4) |
|
More traces show the access to the Entity0::Function_Status register (Control 0x10) bit also yields a Command_Ignored value. val = sdw_read_no_pm(rt711->slave,
SDW_SDCA_CTL(FUNC_NUM_JACK_CODEC,
0, 0x10, 0));
dev_warn(&rt711->slave->dev,
"%s function status read %d %#x\n", __func__, val, val);That is a BIG problem, this means the Function_Status cannot be accessed. In theory the Command_Ignored cannot happen for this sort of register, because that's what we need to read if there is a Command_Ignored reply. So the conclusion is that 4) is the most likely problem, with a TBD dependency between control channel using paged access and Bulk. |
|
@plbossart The ALC711-VD (rt711-sdca) just follows the SDCA v0.6 version. There is no Function_Status control inside. |
|
@plbossart Could you dump some settings while testing? We want to simulate this case.
|
50x4, 4.8 MHz settings are fixed here, you need to convert them to actual register encoding 9243784#diff-905f617727dbd063de023ac974441b3b35b35cba5e37cdd9559bf929d1ac5756R126
3 (all three columns)
4 (one entire row)
0
hstart 1, hstop 3
8
doesn't matter, it's linked to the file size.
doesn't matter, I sent an all zero file with 32768 bytes |
|
@plbossart The designer simulated this condition that he couldn't see the ignored response when reading SDCA registers. |
|
oh, could this be a side effect then where the BPT/BRA transfer accesses an invalid part of the memory without an error reported, but the Command_Ignored is reported during a regular read to a valid address? Did I get this right @shumingfan ? |
|
@plbossart Right, your test should do the BPT/BRA and a regular read at the same time. |
|
Thanks @shumingfan, that helps. I'll close this issue as won't fix since it's an invalid configuration handled the wrong way, but it's invalid to start with. |
plbossart
added
won't fix
When doing a BPT transfer without the DSP, we ALWAYS see an error
This is very odd because the SAME device 6 replies to BPT commands without any errors. @shumingfan @bardliao any idea why this might fail?
full sequence:
The text was updated successfully, but these errors were encountered: