From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752802AbdJKKUe (ORCPT ); Wed, 11 Oct 2017 06:20:34 -0400 Received: from mga03.intel.com ([134.134.136.65]:17055 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750705AbdJKKUc (ORCPT ); Wed, 11 Oct 2017 06:20:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,360,1503385200"; d="scan'208";a="161376998" Date: Wed, 11 Oct 2017 15:54:36 +0530 From: Vinod Koul To: Srinivas Kandagatla Cc: gregkh@linuxfoundation.org, broonie@kernel.org, alsa-devel@alsa-project.org, mark.rutland@arm.com, michael.opdenacker@free-electrons.com, poeschel@lemonage.de, andreas.noever@gmail.com, gong.chen@linux.intel.com, arnd@arndb.de, kheitke@audience.com, bp@suse.de, devicetree@vger.kernel.org, james.hogan@imgtec.com, pawel.moll@arm.com, linux-arm-msm@vger.kernel.org, sharon.dvir1@mail.huji.ac.il, robh+dt@kernel.org, sdharia@codeaurora.org, alan@linux.intel.com, treding@nvidia.com, mathieu.poirier@linaro.org, jkosina@suse.cz, linux-kernel@vger.kernel.org, daniel@ffwll.ch, joe@perches.com, davem@davemloft.net Subject: Re: [alsa-devel] [Patch v6 2/7] slimbus: Add messaging APIs to slimbus framework Message-ID: <20171011102436.GH30097@localhost> References: <20171006155136.4682-1-srinivas.kandagatla@linaro.org> <20171006155136.4682-3-srinivas.kandagatla@linaro.org> <20171011043814.GF30097@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 11, 2017 at 10:42:28AM +0100, Srinivas Kandagatla wrote: > On 11/10/17 05:38, Vinod Koul wrote: > >On Fri, Oct 06, 2017 at 05:51:31PM +0200, srinivas.kandagatla@linaro.org wrote: > > > >> mutex_init(&ctrl->m_ctrl); > >>+ spin_lock_init(&ctrl->tx.lock); > >>+ spin_lock_init(&ctrl->rx.lock); > > > >locks galore :) My assumption is that you want to optimize these? But given > >that audio user is going to be serialized do we practically need two locks? > > > If we remove the locking, It will be issue if we have multiple devices in a > component, which is common atleast with the codec which am looking at. can you explian what you mean by a "device" here? > >>+ switch (mc) { > >>+ case SLIM_MSG_MC_REQUEST_VALUE: > >>+ case SLIM_MSG_MC_REQUEST_INFORMATION: > > > >what does MC refer to? > > Message Code. isnt SLIM_MSG enough :D I think we cna get rid of MC here.. > >>+struct slim_val_inf { > >>+ u16 start_offset; > >>+ u8 num_bytes; > >>+ u8 *rbuf; > >>+ const u8 *wbuf; > > > >can we do read and write, if not it can be a buf which maybe rbuf or wbug > >based on type > With REQUEST_CHANGE_VALUE single command we can read old value at the same > time we can write new value. so that is a read modify write, correct? Is that implemented in HW, if so we need to provide only write value -- ~Vinod