From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Hardik Shah <hardik.t.shah@intel.com>,
<alsa-devel@alsa-project.org>, <linux-kernel@vger.kernel.org>,
<tiwai@suse.de>, <broonie@kernel.org>, <lgirdwood@gmail.com>,
<plai@codeaurora.org>, <patches.audio@intel.com>,
Sanyog Kale <sanyog.r.kale@intel.com>
Subject: Re: [RFC 02/14] SoundWire: Add SoundWire stream documentation
Date: Mon, 14 Nov 2016 17:04:44 +0000 [thread overview]
Message-ID: <20161114170444.GP1575@localhost.localdomain> (raw)
In-Reply-To: <b0d67cc6-f7fb-ea61-29b3-02a7f7c0aac3@linux.intel.com>
On Mon, Nov 14, 2016 at 10:50:10AM -0600, Pierre-Louis Bossart wrote:
>
> >>+SoundWire stream states
> >>+=======================
> >>+Below figure shows the SoundWire stream states and possible state
> >>+transition diagram.
> >>+
> >>+|--------------| |-------------| |--------------| |--------------|
> >>+| ALLOC |---->| CONFIG |---->| PREPARE |---->| ENABLE |
> >>+| STATE | | STATE | | STATE | | STATE |
> >>+|--------------| |-------------| |--------------| |--------------|
> >>+ ^ |
> >>+ | |
> >>+ | |
> >>+ | |
> >>+ | \/
> >>+ |--------------| |--------------| |--------------|
> >>+ | RELEASE |<--------------------| DEPREPARE |<----| DISABLE |
> >>+ | STATE | | STATE | | STATE |
> >>+ |--------------| |--------------| |--------------|
> >>+
> >
> >One minor comment, this looks very similar to the clock
> >frameworks state model, but the clock framework calls it
> >unprepare would there be some milage in aligning to?
>
> The SoundWire spec uses de-prepare, e.g. "De-prepare_Finished"
> I'd rather stick to the wording between a spec and the implementation of
> said spec, rather than introduce a term/concept from an unrelated framework.
> >
Cool we should leave that as is then :-)
> >>+4. Once all the new values are programmed, bus initiates switch to
> >>+alternate bank. Once switch is successful, the port channels enabled on
> >>+previous bank for already active streams are disabled.
>
> This last sentence makes no sense in this context, probably a copy/paste
> that shouldn't be there. The previously active streams remain active in this
> prepare step.
>
> >>+
> >>+5. Ports of Master and Slave for current stream are prepared.
> >>+
> >>+After all above operations are successful, stream state is set to
> >>+SDW_STATE_STRM_PREPARE.
> >>+
> >>+
> >>+SDW_STATE_STRM_ENABLE: Enable state of stream. Operations performed
> >>+before entering in this state:
> >>+1. All the values computed in SDW_STATE_STRM_PREPARE state are
> >>+programmed in alternate bank (bank currently unused). It includes
> >>+programming of already active streams as well.
> >>+
> >>+2. All the Master and Slave port channels for the current stream are
> >>+enabled on alternate bank (bank currently unused).
> >>+
> >
> >This could probably use a little more explaination to show how it
> >differs from step 3/4 in PREPARE, as it looks like all the
> >computed values where applied there. I imagine this is just my lack
> >of understanding rather than an actual issue but even looking at
> >the code I am having a little difficulty tying up these two.
>
> Yes, see above there was an extra sentence that isn't right.
>
> >
> >sdw_prepare_op
> >- sdw_compute_params (prepare step 1/2)
> >- sdw_program_params (prepare step 3)
> >- sdw_update_bus_params (prepare step 4)
> >
> >sdw_enable_op
> >- sdw_program_params (enable step 1)
> >- sdw_update_bus_params (enable step 2)
> >
> >It looks like the params are still basically the same as they
> >were when we called sdw_program_params in prepare.
>
> The parameters are the same except for the channel-enable flags which are
> only programmed and activated via a bank switch in the enable step.
Ah ok that is what is getting pushed out there, thanks for
explaining.
Thanks,
Charles
next prev parent reply other threads:[~2016-11-14 17:04 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 12:40 [RFC 00/14] SoundWire bus driver Hardik Shah
2016-10-21 12:40 ` [RFC 01/14] SoundWire: Add SoundWire bus driver documentation Hardik Shah
2016-11-14 14:15 ` Charles Keepax
2016-11-15 14:29 ` Vinod Koul
2016-11-16 17:59 ` Mark Brown
2016-11-17 5:05 ` Vinod Koul
2016-10-21 12:41 ` [RFC 02/14] SoundWire: Add SoundWire stream documentation Hardik Shah
2016-11-14 15:31 ` Charles Keepax
2016-11-14 16:50 ` Pierre-Louis Bossart
2016-11-14 17:04 ` Charles Keepax [this message]
2016-10-21 12:41 ` [RFC 03/14] SoundWire: Add error handling and locking documentation Hardik Shah
2016-11-14 15:44 ` Charles Keepax
2016-11-15 14:42 ` Vinod Koul
2016-10-21 12:41 ` [RFC 04/14] SoundWire: Add device_id table for SoundWire bus Hardik Shah
2016-10-21 12:41 ` [RFC 05/14] SoundWire: Add SoundWire bus driver interfaces Hardik Shah
2016-11-14 13:17 ` Mark Brown
2016-11-14 17:28 ` [alsa-devel] " Pierre-Louis Bossart
2016-10-21 12:41 ` [RFC 06/14] SoundWire: Add register/unregister APIs Hardik Shah
2016-11-14 13:37 ` Mark Brown
2016-11-15 13:55 ` Vinod Koul
2016-10-21 12:41 ` [RFC 07/14] SoundWire: Add SoundWire Slaves register definitions Hardik Shah
2016-10-21 12:41 ` [RFC 08/14] SoundWire: Add API for Slave registers read/write Hardik Shah
2016-10-21 12:41 ` [RFC 09/14] SoundWire: Add support to handle Slave status change Hardik Shah
2016-11-14 16:08 ` Charles Keepax
2016-11-14 17:38 ` [alsa-devel] " Pierre-Louis Bossart
2016-11-15 9:56 ` Charles Keepax
2016-10-21 12:41 ` [RFC 10/14] SoundWire: Add support for clock stop Hardik Shah
2016-10-21 12:41 ` [RFC 11/14] SoundWire: Add tracing for Slave register read/write Hardik Shah
2016-10-21 12:41 ` [RFC 12/14] regmap: SoundWire: Add regmap support for SoundWire bus Hardik Shah
2016-10-28 18:03 ` Mark Brown
2016-11-02 8:11 ` Hardik Shah
2016-10-21 12:41 ` [RFC 13/14] SoundWire: Add stream and port configuration Hardik Shah
2016-10-21 12:41 ` [RFC 14/14] SoundWire: Add support for SoundWire stream management Hardik Shah
2016-11-14 12:11 ` [RFC 00/14] SoundWire bus driver Mark Brown
2016-11-15 13:37 ` 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=20161114170444.GP1575@localhost.localdomain \
--to=ckeepax@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=hardik.t.shah@intel.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches.audio@intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=plai@codeaurora.org \
--cc=sanyog.r.kale@intel.com \
--cc=tiwai@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).