Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933977AbcKNREv (ORCPT ); Mon, 14 Nov 2016 12:04:51 -0500 Received: from mx0a-001ae601.pphosted.com ([67.231.149.25]:46065 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932755AbcKNREp (ORCPT ); Mon, 14 Nov 2016 12:04:45 -0500 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.wolfsonmicro.com Date: Mon, 14 Nov 2016 17:04:44 +0000 From: Charles Keepax To: Pierre-Louis Bossart CC: Hardik Shah , , , , , , , , Sanyog Kale Subject: Re: [RFC 02/14] SoundWire: Add SoundWire stream documentation Message-ID: <20161114170444.GP1575@localhost.localdomain> References: <1477053673-16021-1-git-send-email-hardik.t.shah@intel.com> <1477053673-16021-3-git-send-email-hardik.t.shah@intel.com> <20161114153159.GM1575@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611140344 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3796 Lines: 87 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