Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM
From: Richard Fitzgerald
Date: Tue Feb 10 2026 - 12:30:29 EST
On 10/02/2026 5:04 pm, Pierre-Louis Bossart wrote:
On 2/10/26 12:08, Holalu Yogendra, Niranjan wrote:
On 2/9/26 20:13, Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxx> wrote:
Subject: Re: [PATCH v1 RESEND] SoundWire: Allow Prepare
command for Simplified_CP_SM
On 2/9/26 08: 09, Niranjan H Y wrote:
In TI device implementations, we've found that some devices withIt would also be good to clarify when the device is actually prepared after the
Simplified_CP_SM still benefit from receiving the Prepare command.
bits are set, if the implementation cannot guarantee that the prepared status is
reached by the end of the frame where the write occurs, then it's definitively
NOT a Simplified_CP_SM.
What happens is the simple_ch_prep_sm bit is not set for those devices, and
the regular state machine is used instead? Is anything broken?
We need to use the same BIOS between Windows and Linux. The BIOS configures
the device as Simplified_CP_SM. The device also expects the Prepare bits to be
set. If the device is configured as generic CP_SM, the status "Port Ready"
bits will not be updated and we end up with port prepare fail errors.
Are you referring to the DPN_IntStat::PortReady bit? IOW do the errors during prepare happen because the interrupt is not generated?
If that is the case, then you should be aware of the thread "soundwire: stream: Prepare ports in parallel to reduce stream start latency", where it was agreed that the use of the PortReady interrupt is broken. We do need to move to a different code where we have a polling loop on the DPN_PrepareStatus::NotFinished bits.
I made a patch to poll for DP prepare finished, instead of using the
interrupt. I haven't sent that patch because this TI patch changes the
same function. I was waiting for this one to be merged and then I would
rebase onto that.
Draft review of polled DP prepare:
https://github.com/thesofproject/linux/pull/5649