[PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Niranjan H Y]

As defined in the MIPI SoundWire specification v1-2 for
Simplified Channel Prepare State Machine (Simplified_CP_SM):

* Figure 141 for the Simplified_CP_SM in the specification
  shows the "Ready" state (NF=0, P=1) that can be reached via
  "Prepare0 OR Prepare1" transitions.
* Table 115 (Stimulus to the Channel Prepare State Machine)
  indicates that Prepare0 and Prepare1 are read-only/"write-ignored"
  bits for Simplified_CP_SM.

In TI device implementations, we've found that some devices with
Simplified_CP_SM still benefit from receiving the Prepare command.

This patch modifies the code to:
1. Send the Prepare command to all devices, including those with
   Simplified_CP_SM
2. Ignore errors returned by devices with Simplified_CP_SM that
   might not support this command

This approach maintains compatibility with all devices while ensuring
proper functionality of dataport operations for devices that can
make use of the Prepare command despite using Simplified_CP_SM.

Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Shuming Fan <shumingf@realtek.com>
---
 drivers/soundwire/stream.c | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c
index 38c9dbd35..33605dc83 100644
--- a/drivers/soundwire/stream.c
+++ b/drivers/soundwire/stream.c
@@ -504,14 +504,19 @@ static int sdw_prep_deprep_slave_ports(struct sdw_bus *bus,
 	sdw_do_port_prep(s_rt, prep_ch, prep ? SDW_OPS_PORT_PRE_PREP : SDW_OPS_PORT_PRE_DEPREP);
 
 	/* Prepare Slave port implementing CP_SM */
-	if (!simple_ch_prep_sm) {
-		addr = SDW_DPN_PREPARECTRL(p_rt->num);
-
-		if (prep)
-			ret = sdw_write_no_pm(s_rt->slave, addr, p_rt->ch_mask);
-		else
-			ret = sdw_write_no_pm(s_rt->slave, addr, 0x0);
+	/* For Simplified_CP_SM, MIPI SoundWire specification v1-2 indicates
+	 * Prepare bits are "write-ignored" - this means devices may ignore the command.
+	 * Some devices still benefit from receiving this command even when using
+	 * Simplified_CP_SM, so we send it to all devices and ignore errors from those
+	 * that don't support it.
+	 */
+	addr = SDW_DPN_PREPARECTRL(p_rt->num);
+	if (prep)
+		ret = sdw_write_no_pm(s_rt->slave, addr, p_rt->ch_mask);
+	else
+		ret = sdw_write_no_pm(s_rt->slave, addr, 0x0);
 
+	if (!simple_ch_prep_sm) {
 		if (ret < 0) {
 			dev_err(&s_rt->slave->dev,
 				"Slave prep_ctrl reg write failed\n");
@@ -530,6 +535,11 @@ static int sdw_prep_deprep_slave_ports(struct sdw_bus *bus,
 				"Chn prep failed for port %d: %d\n", prep_ch.num, ret);
 			return ret;
 		}
+	} else {
+		/* Some device return error for the prepare command,
+		 * ignore the error for Simplified CP_SM
+		 */
+		ret = 0;
 	}
 
 	/* Inform slaves about ports prepared */
-- 
2.43.0

Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Pierre-Louis Bossart]

On 2/9/26 08:09, Niranjan H Y wrote:
> As defined in the MIPI SoundWire specification v1-2 for
> Simplified Channel Prepare State Machine (Simplified_CP_SM):
> 
> * Figure 141 for the Simplified_CP_SM in the specification
>   shows the "Ready" state (NF=0, P=1) that can be reached via
>   "Prepare0 OR Prepare1" transitions.
> * Table 115 (Stimulus to the Channel Prepare State Machine)
>   indicates that Prepare0 and Prepare1 are read-only/"write-ignored"
>   bits for Simplified_CP_SM.
> 
> In TI device implementations, we've found that some devices with
> Simplified_CP_SM still benefit from receiving the Prepare command.

This is a bit weird really...

There is no such thing as a Prepare command, what is used is a regular write that sets or clears Prepare bits in port registers. If those bits are NOT read-only/write-ignored, then presumably they are writable. One could then argue the device does not follow the Simplified_CP_SM state machine but the generic one.
It would also be good to clarify when the device is actually prepared after the 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?

> This patch modifies the code to:
> 1. Send the Prepare command to all devices, including those with
>    Simplified_CP_SM
> 2. Ignore errors returned by devices with Simplified_CP_SM that
>    might not support this command
> 
> This approach maintains compatibility with all devices while ensuring
> proper functionality of dataport operations for devices that can
> make use of the Prepare command despite using Simplified_CP_SM.
> 
> Signed-off-by: Niranjan H Y <niranjan.hy@ti.com>
> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> Tested-by: Shuming Fan <shumingf@realtek.com>
> ---
>  drivers/soundwire/stream.c | 24 +++++++++++++++++-------
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c
> index 38c9dbd35..33605dc83 100644
> --- a/drivers/soundwire/stream.c
> +++ b/drivers/soundwire/stream.c
> @@ -504,14 +504,19 @@ static int sdw_prep_deprep_slave_ports(struct sdw_bus *bus,
>  	sdw_do_port_prep(s_rt, prep_ch, prep ? SDW_OPS_PORT_PRE_PREP : SDW_OPS_PORT_PRE_DEPREP);
>  
>  	/* Prepare Slave port implementing CP_SM */
> -	if (!simple_ch_prep_sm) {
> -		addr = SDW_DPN_PREPARECTRL(p_rt->num);
> -
> -		if (prep)
> -			ret = sdw_write_no_pm(s_rt->slave, addr, p_rt->ch_mask);
> -		else
> -			ret = sdw_write_no_pm(s_rt->slave, addr, 0x0);
> +	/* For Simplified_CP_SM, MIPI SoundWire specification v1-2 indicates
> +	 * Prepare bits are "write-ignored" - this means devices may ignore the command.
> +	 * Some devices still benefit from receiving this command even when using
> +	 * Simplified_CP_SM, so we send it to all devices and ignore errors from those
> +	 * that don't support it.
> +	 */
> +	addr = SDW_DPN_PREPARECTRL(p_rt->num);
> +	if (prep)
> +		ret = sdw_write_no_pm(s_rt->slave, addr, p_rt->ch_mask);
> +	else
> +		ret = sdw_write_no_pm(s_rt->slave, addr, 0x0);
>  
> +	if (!simple_ch_prep_sm) {
>  		if (ret < 0) {
>  			dev_err(&s_rt->slave->dev,
>  				"Slave prep_ctrl reg write failed\n");
> @@ -530,6 +535,11 @@ static int sdw_prep_deprep_slave_ports(struct sdw_bus *bus,
>  				"Chn prep failed for port %d: %d\n", prep_ch.num, ret);
>  			return ret;
>  		}
> +	} else {
> +		/* Some device return error for the prepare command,
> +		 * ignore the error for Simplified CP_SM

that comment is misleading anyways, it's not 'some device' it's ALL the conformant devices that will return Command_Ignored when trying to write read-only bits. You haven't described what the TI devices would return in this case.

> +		 */
> +		ret = 0;
>  	}
>  
>  	/* Inform slaves about ports prepared */

Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Holalu Yogendra, Niranjan]

> On 2/9/26 20:13, Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> 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 with
> > Simplified_CP_SM still benefit from receiving the Prepare command.
> It would also be good to clarify when the device is actually prepared after the
> 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.

So, setting the device to simplified CP_SM and ignoring the "port ready" bits is the
best option we have.

The TI's HW is implemented referring to the "Figure 141 Channel Prepare State 
Machine" for Simplified_CP_SM of the spec. where Prepare0 OR Prepare1 are shown in the
image interpreting it as setting prepare/de-prepare bits.

> > +	} else {
> > +		/* Some device return error for the prepare command,
> > +		 * ignore the error for Simplified CP_SM
> 
> that comment is misleading anyways, it's not 'some device' it's ALL the
> conformant devices that will return Command_Ignored when trying to write
> read-only bits. You haven't described what the TI devices would return in this
> case.
TI device doesn't return any error code while setting the  prepare bits command while
in Simplified_CP_SM mode. It accepts the write to the register without complaint.

I agree that the comment could  be updated. We should indicate that we're 
deliberately sending writes to what should be write-ignored bits for compatibility 
reasons, while ensuring any potential errors from fully spec-compliant devices are 
handled gracefully.

Regards
Niranjan

Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Pierre-Louis Bossart]

On 2/10/26 12:08, Holalu Yogendra, Niranjan wrote:
>> On 2/9/26 20:13, Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> 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 with
>>> Simplified_CP_SM still benefit from receiving the Prepare command.
>> It would also be good to clarify when the device is actually prepared after the
>> 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.

So is the problem in the interrupt generation, or is the problem with the 'Not Finished' bits?

> So, setting the device to simplified CP_SM and ignoring the "port ready" bits is the
> best option we have.
> 
> The TI's HW is implemented referring to the "Figure 141 Channel Prepare State 
> Machine" for Simplified_CP_SM of the spec. where Prepare0 OR Prepare1 are shown in the
> image interpreting it as setting prepare/de-prepare bits.

right, but are the 'Not Finished' bits updated after the write when the transition to the prepared state is complete?
If that works then an alternate solution to this patch would be to quirk all TI devices to use the regular state machine, and use the polling loop as suggested by Richard Fitzgerald.

>>> +	} else {
>>> +		/* Some device return error for the prepare command,
>>> +		 * ignore the error for Simplified CP_SM
>>
>> that comment is misleading anyways, it's not 'some device' it's ALL the
>> conformant devices that will return Command_Ignored when trying to write
>> read-only bits. You haven't described what the TI devices would return in this
>> case.
> TI device doesn't return any error code while setting the  prepare bits command while
> in Simplified_CP_SM mode. It accepts the write to the register without complaint.
> 
> I agree that the comment could  be updated. We should indicate that we're 
> deliberately sending writes to what should be write-ignored bits for compatibility 
> reasons, while ensuring any potential errors from fully spec-compliant devices are 
> handled gracefully.
I think it's worth exploring what happens if the PortReady interrupt is not used. If that's broken as well, then your solution would work but needs more/better comments indeed.

Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Richard Fitzgerald]

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@linux.dev> 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 with
>>>> Simplified_CP_SM still benefit from receiving the Prepare command.
>>> It would also be good to clarify when the device is actually prepared after the
>>> 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

Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Pierre-Louis Bossart]

On 2/10/26 18:29, Richard Fitzgerald wrote:
> 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@linux.dev> 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 with
>>>>> Simplified_CP_SM still benefit from receiving the Prepare command.
>>>> It would also be good to clarify when the device is actually prepared after the
>>>> 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

IMHO it makes more sense to fix first a conceptual issue, and then add whatever is needed for a specific vendor.
The second part could be a quirk to use the regular state machine, or this additional write if that's not enough.

Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Richard Fitzgerald]

On 10/02/2026 8:28 pm, Pierre-Louis Bossart wrote:
> On 2/10/26 18:29, Richard Fitzgerald wrote:
>> 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@linux.dev> 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 with
>>>>>> Simplified_CP_SM still benefit from receiving the Prepare command.
>>>>> It would also be good to clarify when the device is actually prepared after the
>>>>> 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
> 
> IMHO it makes more sense to fix first a conceptual issue, and then add whatever is needed for a specific vendor.
> The second part could be a quirk to use the regular state machine, or this additional write if that's not enough.
> 

Ok. I'll watch this thread. Let me know if you want me to send my patch
and TI rebase onto it.

If I could get some confirmation on that draft Github pull that it
doesn't break anything, that would be helpful.

RE: [EXTERNAL] Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Holalu Yogendra, Niranjan]

Apologies for the late response. 
> On 2/10/26 22:34 Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> wrote:
> Subject: Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM
> 
> On 2/10/26 12: 08, Holalu Yogendra, Niranjan wrote: >> On 2/9/26 20: 13,
> Pierre-Louis Bossart <pierre-louis. bossart@ linux. dev> wrote: 
> On 2/10/26 12:08, Holalu Yogendra, Niranjan wrote:
> >> On 2/9/26 20:13, Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> wrote:
> >> On 2/9/26 08: 09, Niranjan H Y wrote:

> 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.

Thanks for the info.

> So is the problem in the interrupt generation, or is the problem with the 'Not
> Finished' bits?
Both, while using Full CP_SM on a simplified CP_SM device:
* First problem: the interrupt will not get generated on a simple CP_SM device.
* Second problem: even after timeout waiting for interrupt with huge delays,
  we can't rely on 'Not Finished' bits, causing timeout errors.
  In the current code for full CP_SM, 'Not Finished' = 0 is a good response even
  with timeout.

> If that works then an alternate solution to this patch would be to quirk all TI
> devices to use the regular state machine, and use the polling loop as
> suggested by Richard Fitzgerald.
> I think it's worth exploring what happens if the PortReady interrupt is not
> used. If that's broken as well, then your solution would work but needs
> more/better comments indeed.
Currently, we have one device which needs this workaround.
Initially, it looked like a generic solution to me. However, if it makes sense,
I can implement sdw_slave_ops->port_prep to make custom changes
for the required devices only, handle any errors and drop this patch.
Please suggest.

Regards
Niranjan

Re: [EXTERNAL] Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Richard Fitzgerald]

On 12/02/2026 4:17 pm, Holalu Yogendra, Niranjan wrote:
> Apologies for the late response.
>> On 2/10/26 22:34 Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> wrote:
>> Subject: Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM
>>
>> On 2/10/26 12: 08, Holalu Yogendra, Niranjan wrote: >> On 2/9/26 20: 13,
>> Pierre-Louis Bossart <pierre-louis. bossart@ linux. dev> wrote:
>> On 2/10/26 12:08, Holalu Yogendra, Niranjan wrote:
>>>> On 2/9/26 20:13, Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> wrote:
>>>> On 2/9/26 08: 09, Niranjan H Y wrote:
> 
>> 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.
> 
> Thanks for the info.
> 
>> So is the problem in the interrupt generation, or is the problem with the 'Not
>> Finished' bits?
> Both, while using Full CP_SM on a simplified CP_SM device:
> * First problem: the interrupt will not get generated on a simple CP_SM device.
> * Second problem: even after timeout waiting for interrupt with huge delays,
>    we can't rely on 'Not Finished' bits, causing timeout errors.
>    In the current code for full CP_SM, 'Not Finished' = 0 is a good response even
>    with timeout.
> 
That's because it _IS_ a good response. If the part is reporting
NotFinished=0, then it's good to go and we don't need to treat it as a
timeout. The timeout is caused by the deadlock that Pierre mentioned.
Full CP_SM will always timeout because that code is holding the bus
lock, which blocks the interrupt handler.

Ignoring the timeout if NotFinished=0 was a workaround until I found
time to fix the interrupt handling. Otherwise full CP_SM would never
work.

We've now decided to replace that code with a polling loop instead of
using interrupts.

>> If that works then an alternate solution to this patch would be to quirk all TI
>> devices to use the regular state machine, and use the polling loop as
>> suggested by Richard Fitzgerald.
>> I think it's worth exploring what happens if the PortReady interrupt is not
>> used. If that's broken as well, then your solution would work but needs
>> more/better comments indeed.
> Currently, we have one device which needs this workaround.
> Initially, it looked like a generic solution to me. However, if it makes sense,
> I can implement sdw_slave_ops->port_prep to make custom changes
> for the required devices only, handle any errors and drop this patch.
> Please suggest.
> 
> Regards
> Niranjan
> 

Re: [EXTERNAL] Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Pierre-Louis Bossart]

>>> 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.
>>
>> Thanks for the info.
>>
>>> So is the problem in the interrupt generation, or is the problem with the 'Not
>>> Finished' bits?
>> Both, while using Full CP_SM on a simplified CP_SM device:
>> * First problem: the interrupt will not get generated on a simple CP_SM device.
>> * Second problem: even after timeout waiting for interrupt with huge delays,
>>    we can't rely on 'Not Finished' bits, causing timeout errors.
>>    In the current code for full CP_SM, 'Not Finished' = 0 is a good response even
>>    with timeout.
>>
> That's because it _IS_ a good response. If the part is reporting
> NotFinished=0, then it's good to go and we don't need to treat it as a
> timeout. The timeout is caused by the deadlock that Pierre mentioned.
> Full CP_SM will always timeout because that code is holding the bus
> lock, which blocks the interrupt handler.
> 
> Ignoring the timeout if NotFinished=0 was a workaround until I found
> time to fix the interrupt handling. Otherwise full CP_SM would never
> work.
> 
> We've now decided to replace that code with a polling loop instead of
> using interrupts.

IOW the suggestion would be to use Richard's patch and force the drive to use a regular state machine.
see https://github.com/thesofproject/linux/pull/5649

>>> If that works then an alternate solution to this patch would be to quirk all TI
>>> devices to use the regular state machine, and use the polling loop as
>>> suggested by Richard Fitzgerald.
>>> I think it's worth exploring what happens if the PortReady interrupt is not
>>> used. If that's broken as well, then your solution would work but needs
>>> more/better comments indeed.
>> Currently, we have one device which needs this workaround.
>> Initially, it looked like a generic solution to me. However, if it makes sense,
>> I can implement sdw_slave_ops->port_prep to make custom changes
>> for the required devices only, handle any errors and drop this patch.
>> Please suggest.

But if you want to keep following the CP_SM state machine, then you could indeed add the required write in a port_prep() routine.
That'd fine as well, you'd be relying on what the core SoundWire stream management provides - namely a means to do device-specific stuff before/after port setup.

Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM

[Holalu Yogendra, Niranjan]

> On 02/13/26 20:27 Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> wrote:
> Subject: Re: [PATCH v1 RESEND] SoundWire: Allow Prepare command for Simplified_CP_SM
> 
> > That's because it _IS_ a good response. If the part is reporting
> > NotFinished=0, then it's good to go and we don't need to treat it as a
> > timeout. The timeout is caused by the deadlock that Pierre mentioned.
> > Full CP_SM will always timeout because that code is holding the bus
> > lock, which blocks the interrupt handler.
> >
> > Ignoring the timeout if NotFinished=0 was a workaround until I found
> > time to fix the interrupt handling. Otherwise full CP_SM would never
> > work.
> >
> > We've now decided to replace that code with a polling loop instead of
> > using interrupts.
> 
> IOW the suggestion would be to use Richard's patch and force the drive to
> use a regular state machine.
> see https://github.com/thesofproject/linux/pull/5649
I checked this PR. Seems to be working as expected. But,

> 
> But if you want to keep following the CP_SM state machine, then you could
> indeed add the required write in a port_prep() routine.
> That'd fine as well, you'd be relying on what the core SoundWire stream
> management provides - namely a means to do device-specific stuff
> before/after port setup.
please ignore the patch in this thread.
I have sent a new patch to do handle this in codec driver itself
 ASoC: tas2783A: add explicit port prepare handling