All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2016-11-14 17:04 UTC|newest]

Thread overview: 41+ 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-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 15:31     ` Charles Keepax
2016-11-14 16:50     ` Pierre-Louis Bossart
2016-11-14 17:04       ` Charles Keepax [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-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 16:08     ` Charles Keepax
2016-11-14 17:38     ` [alsa-devel] " Pierre-Louis Bossart
2016-11-15  9:56       ` Charles Keepax
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 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.