From: Vinod Koul <vkoul@kernel.org>
To: Bard Liao <yung-chuan.liao@linux.intel.com>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
gregkh@linuxfoundation.org, srinivas.kandagatla@linaro.org,
rander.wang@linux.intel.com, hui.wang@canonical.com,
pierre-louis.bossart@linux.intel.com, sanyog.r.kale@intel.com,
bard.liao@intel.com
Subject: Re: [RESEND PATCH 0/4] soundwire: only use CLOCK_STOP_MODE0 and handle -ENODATA errors in clock stop/start sequences
Date: Tue, 11 May 2021 17:52:34 +0530 [thread overview]
Message-ID: <YJp3CvCLt/xWDxgr@vkoul-mobl.Dlink> (raw)
In-Reply-To: <20210511030048.25622-1-yung-chuan.liao@linux.intel.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: Bard Liao <yung-chuan.liao@linux.intel.com>
Cc: alsa-devel@alsa-project.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org,
pierre-louis.bossart@linux.intel.com, hui.wang@canonical.com,
sanyog.r.kale@intel.com, rander.wang@linux.intel.com,
bard.liao@intel.com
Subject: Re: [RESEND PATCH 0/4] soundwire: only use CLOCK_STOP_MODE0 and handle -ENODATA errors in clock stop/start sequences
Date: Tue, 11 May 2021 17:52:34 +0530 [thread overview]
Message-ID: <YJp3CvCLt/xWDxgr@vkoul-mobl.Dlink> (raw)
In-Reply-To: <20210511030048.25622-1-yung-chuan.liao@linux.intel.com>
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
next prev parent reply other threads:[~2021-05-11 12:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 3:00 [RESEND PATCH 0/4] soundwire: only use CLOCK_STOP_MODE0 and handle -ENODATA errors in clock stop/start sequences Bard Liao
2021-05-11 3:00 ` Bard Liao
2021-05-11 3:00 ` [RESEND PATCH 1/4] soundwire: bus: only use CLOCK_STOP_MODE0 and fix confusions Bard Liao
2021-05-11 3:00 ` Bard Liao
2021-05-11 3:00 ` [RESEND PATCH 2/4] soundwire: add missing kernel-doc description Bard Liao
2021-05-11 3:00 ` Bard Liao
2021-05-11 3:00 ` [RESEND PATCH 3/4] soundwire: bus: handle -ENODATA errors in clock stop/start sequences Bard Liao
2021-05-11 3:00 ` Bard Liao
2021-05-11 3:00 ` [RESEND PATCH 4/4] soundwire: bus: add missing \n in dynamic debug Bard Liao
2021-05-11 3:00 ` Bard Liao
2021-05-11 12:22 ` Vinod Koul [this message]
2021-05-11 12:22 ` [RESEND PATCH 0/4] soundwire: only use CLOCK_STOP_MODE0 and handle -ENODATA errors in clock stop/start sequences Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YJp3CvCLt/xWDxgr@vkoul-mobl.Dlink \
--to=vkoul@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=bard.liao@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hui.wang@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rander.wang@linux.intel.com \
--cc=sanyog.r.kale@intel.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=yung-chuan.liao@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.