RE: [PATCH 2/2] soundwire: Intel: stop sdw clock in system suspend

[Liao, Bard]

> -----Original Message-----
> From: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxx>
> Sent: Wednesday, July 1, 2026 8:01 PM
> To: Richard Fitzgerald <rf@xxxxxxxxxxxxxxxxxxxxx>; Liao, Bard
> <bard.liao@xxxxxxxxx>; Bard Liao <yung-chuan.liao@xxxxxxxxxxxxxxx>; linux-
> sound@xxxxxxxxxxxxxxx; vkoul@xxxxxxxxxx
> Cc: vinod.koul@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> peter.ujfalusi@xxxxxxxxxxxxxxx; Richard Fitzgerald
> <Richard.Fitzgerald@xxxxxxxxxx>
> Subject: Re: [PATCH 2/2] soundwire: Intel: stop sdw clock in system suspend
> 
> On 7/1/26 13:55, Pierre-Louis Bossart wrote:
> >
> >> If the Manager doesn't send a clock-stop, the peripherals don't get a
> >> notification that they can enter a lower-power mode. The clock suddenly
> >> disappears without warning and without the peripherals being notified
> >> why, so they don't have any information to know what is happening.
> >
> > that's not quite right, see below.
> >
> >> The Manager should send a clock-stop notification before stopping the
> >> clock.
> >
> > That's exactly the existing logic in drivers/soundwire/bus.c, the core does
> notify all peripheral drivers of a clock stop transition.
> >
> > sdw_slave_clk_stop_callback(slave, SDW_CLK_PRE_PREPARE);
> > sdw_slave_clk_stop_callback(slave, SDW_CLK_POST_PREPARE);
> >
> > These pre- and post callback that can be used by the peripheral for imp-def
> actions.
> >
> > I am not sure if the POST_PREPARE makes sense, since the clock is already
> stopped the peripheral cannot be programmed. IIRC it was added for
> symmetry.
> > The PRE_PREPARE is most likely what you are looking for in the
> implementation of the drv->ops->clk_stop callback.
> >
> > Hope this helps!
> 
> Oh and in the case of a system suspend, then you also get the notification in
> the driver suspend callback. In that case no need to be notified of the implicit
> bus teardown, you can program the peripheral to enter lower power. You do
> not need any clock stop mechanisms to deal with system suspend
> optimizations.

The point is that the SDW bus clock will stop anyway in system suspend
even though sdw_cdns_clock_stop() is not called.
And the peripheral will not get the clock-stop notification in this case.
Not sure will codec driver's system suspend callback launch before the
sdw bus clock getting stopped. And how to ensure it?