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

["Holalu Yogendra, Niranjan" <niranjan.hy@ti.com>]

> 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