alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>,
	Hardik Shah <hardik.t.shah@intel.com>
Cc: 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 10:50:10 -0600	[thread overview]
Message-ID: <b0d67cc6-f7fb-ea61-29b3-02a7f7c0aac3@linux.intel.com> (raw)
In-Reply-To: <20161114153159.GM1575@localhost.localdomain>


>> +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.
>
>> +
>> +SoundWire Stream State Operations
>> +==================================
>> +Below section explains the operations done by the bus driver on
>> +Master(s) and Slave(s) as part of stream state transitions.
>> +
>> +SDW_STATE_STRM_ALLOC: Allocation state for stream. This is the entry
>> +state of the stream. Operations performed before entering in this
>> +state:
>> +1. An unique stream tag is assigned to stream. This stream tag is used
>
> A unique

ok

>
>> +as a reference for all the operations performed on stream.
>> +
>> +2. The resources required for holding stream runtime information are
>> +allocated and initialized. This holds all stream related information
>> +such as stream type (PCM/PDM) and parameters, Master and Slave interface
>> +associated with the stream, reference counting, stream state etc.
>> +
>> +After all above operations are successful, stream state is set to
>> +SDW_STATE_STRM_ALLOC.
>> +
>> +
>> +SDW_STATE_STRM_CONFIG: Configuration state of stream. Operations
>> +performed before entering in this state:
>> +1. The resources allocated for stream information in
>> +SDW_STATE_STRM_ALLOC state are updated. This includes stream parameters,
>> +Masters and Slaves runtime information associated with the stream.
>> +
>> +2. All the Masters and Slaves associated with the stream updates the
>> +port configuration to bus driver. This includes port numbers allocated
>> +by Master(s) and Slave(s) for this stream.
>> +
>> +After all above operations are successful, stream state is set to
>> +SDW_STATE_STRM_CONFIG.
>> +
>> +
>> +SDW_STATE_STRM_PREPARE: Prepare state of stream. Operations performed
>> +before entering in this state:
>> +1. Bus parameters such as bandwidth, frame shape, clock frequency, SSP
>> +interval are computed based on current stream as well as already active
>> +streams on bus. Re-computation is required to accommodate current stream
>> +on the bus.
>> +
>> +2. Transport parameters of all Master and Slave ports are computed for
>> +the current as well as already active stream based on above calculated
>> +frame shape and clock frequency.
>> +
>> +3. Computed bus and transport parameters are programmed in Master and
>> +Slave registers. The banked registers programming is done on the
>> +alternate bank (bank currently unused). Port channels are enabled for
>> +the already active streams on the alternate bank (bank currently
>> +unused). This is done in order to not to disrupt already active
>> +stream(s).
>> +
>> +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.

  reply	other threads:[~2016-11-14 16:50 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 [this message]
2016-11-14 17:04       ` Charles Keepax
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=b0d67cc6-f7fb-ea61-29b3-02a7f7c0aac3@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=ckeepax@opensource.wolfsonmicro.com \
    --cc=hardik.t.shah@intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches.audio@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).