[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YJp3CvCLt/xWDxgr@vkoul-mobl.Dlink>
Date: Tue, 11 May 2021 17:52:34 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Bard Liao <yung-chuan.liao@...ux.intel.com>
Cc: alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
gregkh@...uxfoundation.org, srinivas.kandagatla@...aro.org,
rander.wang@...ux.intel.com, hui.wang@...onical.com,
pierre-louis.bossart@...ux.intel.com, sanyog.r.kale@...el.com,
bard.liao@...el.com
Subject: Re: [RESEND PATCH 0/4] soundwire: only use CLOCK_STOP_MODE0 and
handle -ENODATA errors in clock stop/start sequences
On 11-05-21, 11:00, Bard Liao wrote:
> Existing devices and implementations only support the required
> CLOCK_STOP_MODE0. All the code related to CLOCK_STOP_MODE1 has not
> been tested and is highly questionable, with a clear confusion between
> CLOCK_STOP_MODE1 and the simple clock stop state machine.
>
> This patch removes all usages of CLOCK_STOP_MODE1 - which has no
> impact on any solution - and fixes the use of the simple clock stop
> state machine. The resulting code should be a lot more symmetrical and
> easier to maintain.
>
> Note that CLOCK_STOP_MODE1 is not supported in the SoundWire Device
> Class specification so it's rather unlikely that we need to re-add
> this mode later.
>
> If a device lost sync and can no longer ACK a command, it may not be
> able to enter a lower-power state but it will still be able to resync
> when the clock restarts. In those cases, we want to continue with the
> clock stop sequence.
>
> This patch modifies the behavior during clock stop sequences to only
> log errors unrelated to -ENODATA/Command_Ignored. The flow is also
> modified so that loops continue to prepare/deprepare other devices
> even when one seems to have lost sync.
>
> When resuming the clocks, all issues are logged with a dev_warn(),
> previously only some of them were checked. This is the only part that
> now differs between the clock stop entry and clock stop exit
> sequences: while we don't want to stop the suspend flow, we do want
> information on potential issues while resuming, as they may have
> ripple effects.
>
> For consistency the log messages are also modified to be unique and
> self-explanatory. Errors in sdw_slave_clk_stop_callback() were
> removed, they are now handled in the caller.
Applied, thanks
--
~Vinod
Powered by blists - more mailing lists