From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
alsa-devel@alsa-project.org
Cc: linux-kernel@vger.kernel.org, tiwai@suse.de, broonie@kernel.org,
vkoul@kernel.org, gregkh@linuxfoundation.org, jank@cadence.com,
slawomir.blauciak@intel.com,
Bard liao <yung-chuan.liao@linux.intel.com>,
Rander Wang <rander.wang@linux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
Hui Wang <hui.wang@canonical.com>,
Sanyog Kale <sanyog.r.kale@intel.com>
Subject: Re: [PATCH] soundwire: stream: only change state if needed
Date: Tue, 17 Mar 2020 10:31:29 -0500 [thread overview]
Message-ID: <7a362c6a-364e-499a-e841-0a919f48bf84@linux.intel.com> (raw)
In-Reply-To: <7c7b334d-ae5c-35f6-9cf3-04700677211f@linaro.org>
>>>> The change below would be an error case for Intel, so it's probably
>>>> better if we go with your suggestion. You have a very specific state
>>>> handling due to your power amps and it's probably better to keep it
>>>> platform-specific.
>>>
>>> Just trying to understand, why would it be error for Intel case?
>>>
>>> IMO, If stream state is SDW_STREAM_ENABLED that also implicit that
>>> its prepared too. Similar thing with SDW_STREAM_DEPREPARED.
>>> Isn't it?
>>
>> the stream state is a scalar value, not a mask. The state machine only
>> allows transition from CONFIGURED TO PREPARED or from DEPREPARED TO
>> PREPARED, or DISABLED to PREPARED.
>> There is no allowed transition from ENABLED TO PREPARED, you have to
>> go through the DISABLED state and make sure a bank switch occurred,
>> and re-do a bank switch to prepare again.
> I agree with you if are on single dai case. Am happy to move to stream
> handling to machine driver for now.
>
> But this also means that in cases like multi-codec its not recommended
> to call sdw_prepare and sdw_enable in a single function from codec.
> Which might be worth documenting.
Well, the bigger question is why use sdw_stream functions at the codec
level in the first place? All other codec drivers seem to have no issue
leaving the dais owned by the master control stream state changes.
I am not saying I object or it's bad, just that there were significant
changes in usages of the 'stream' concept since it was introduced, as
well as threads in MIPI circles to clarify the prepare/enable
dependencies, so it'd be useful to have a complete picture of what
different platforms need/want.
next prev parent reply other threads:[~2020-03-17 15:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 10:51 [PATCH] soundwire: stream: only change state if needed Pierre-Louis Bossart
2020-03-17 11:53 ` Srinivas Kandagatla
2020-03-17 12:22 ` Pierre-Louis Bossart
2020-03-17 12:43 ` Srinivas Kandagatla
2020-03-17 13:04 ` Srinivas Kandagatla
2020-03-17 13:19 ` Pierre-Louis Bossart
2020-03-17 15:07 ` Srinivas Kandagatla
2020-03-17 15:31 ` Pierre-Louis Bossart [this message]
2020-03-20 14:15 ` Vinod Koul
2020-03-20 14:33 ` Pierre-Louis Bossart
2020-03-23 12:46 ` 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=7a362c6a-364e-499a-e841-0a919f48bf84@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hui.wang@canonical.com \
--cc=jank@cadence.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rander.wang@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=sanyog.r.kale@intel.com \
--cc=slawomir.blauciak@intel.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=tiwai@suse.de \
--cc=vkoul@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox