From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 07A69C433EF for ; Thu, 25 Nov 2021 06:24:59 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 36EB01769; Thu, 25 Nov 2021 07:24:07 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 36EB01769 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1637821497; bh=gbK6NiU9VK1qdHHrJL9D6I34RF1fumvAqWl/aIJJPd8=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=mZwLYjwNllU8HT9dyngyhpmFizXE5spfH+Qra+XOND+z1Uz3JMPminWbE7cAMCZC5 HMPKlPg6nIcpEtcFwYyiRJNZBFc3xucHcPzmYmUZO5ONrbgveUhWuKtDd8qdUClZmn I1LFgzv8glTZlXkXrLdbioRa4i8EoVKpScznjUNc= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id BC767F80430; Thu, 25 Nov 2021 07:24:06 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id A8E83F804AC; Thu, 25 Nov 2021 07:24:05 +0100 (CET) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id BBC31F80087 for ; Thu, 25 Nov 2021 07:23:57 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz BBC31F80087 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="eBkXht65" Received: by mail-pf1-x42e.google.com with SMTP id o4so4911340pfp.13 for ; Wed, 24 Nov 2021 22:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=kioAbeV26jtOfLhbsus8RZ8a8iejlIcHXqYXJ7To1Ns=; b=eBkXht65eaQyuRQDrrqCwhAyWn3xzgvUxbldnoSVNCmLIw5i7yhixiswI7oX6tDXIn e5VxmyxOwzGNfTqxQYytEWv+s4+GcFrVweqtrK/1Z76qFlfXaq0g925E6SR3StK2J+j/ FB6zzBJ6IP07wKtdatpdYqJS0QNNQqTErPT+Rp5noIa2gs3eZInhIbe12dJwHI5EXaKm jSfsYO10l/rSZmurWnXJb9C9AaQW9o1SviDRMUk6PXZlVVZFipwQ4uji1PKMVUw3Mc3z +AoumEWKC9YLtfDNGAhWOeSfQxHNMpo4Zl1Ws3XBY3FvKe9zAODqAohbXMerXt0Q3aSe WXtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=kioAbeV26jtOfLhbsus8RZ8a8iejlIcHXqYXJ7To1Ns=; b=OCsq6FTaYR9STqOMc4iQsmibfOVH98fvxtH3/7i8thFrzyy6jR7h8cUthRqCqzmPPH 1opG9IjsXUy+bXcUP+FxFn+HxuH79NARfD6OWiCk19zO1g/7OnmsDY4l0Zg7q8214GQe J5X8ETwRLhiv0UJLfxMkFu4U9AG6va/ZBw+y5Mpe6GpviJQ+VqZuSocEGDfGlDOANLhm Zk0U5+8j6jJzkll1ovKyUMk9FxGSYSzTgkRA6Bk7pXfCu8sJ6jUnhrL3jh72Uz/s4vBQ a7hdTXnwGwXP/Qe0ERK/bXlHZRToTjnEX4PW6pOxZ8w2ygsvHSdQltT5APSzDnARrbc4 akGA== X-Gm-Message-State: AOAM533fg8W1kiN95zxVeNelFt4uDEtDXMPlqy5ILlMLb1BBGDPrs++K bVUaC0Oc+LsDCOXM6EWNQX5Dig== X-Google-Smtp-Source: ABdhPJzZmfrw/Y/XnG3KSGm70RCpboamkYNWMx5n6NPi3BL1desf895RZ7uwO1XPBwJ0K0TV+4KGoQ== X-Received: by 2002:a63:481e:: with SMTP id v30mr13663106pga.33.1637821433350; Wed, 24 Nov 2021 22:23:53 -0800 (PST) Received: from google.com ([2401:fa00:1:10:cd6a:1959:1c65:cc19]) by smtp.gmail.com with ESMTPSA id u11sm1800235pfk.152.2021.11.24.22.23.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Nov 2021 22:23:53 -0800 (PST) Date: Thu, 25 Nov 2021 14:23:48 +0800 From: Tzung-Bi Shih To: "allen-kh.cheng" Subject: Re: [PATCH v3 2/3] mailbox: mediatek: add support for adsp mailbox controller Message-ID: References: <20211124084514.28002-1-allen-kh.cheng@mediatek.com> <20211124084514.28002-3-allen-kh.cheng@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: "devicetree@vger.kernel.org" , Linux-ALSA , Kai Vehmanen , "cujomalainey@google.com" , Daniel Baluta , Mark Brown , Jassi Brar , Liam Girdwood , "linux-kernel@vger.kernel.org" , Project_Global_Chrome_Upstream_Group , Rob Herring , "linux-mediatek@lists.infradead.org" , Ranjani Sridharan , Matthias Brugger , Takashi Iwai , Pierre-Louis Bossart , "linux-arm-kernel@lists.infradead.org" , "sound-open-firmware@alsa-project.org" X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Thu, Nov 25, 2021 at 09:51:27AM +0800, allen-kh.cheng wrote: > On Wed, 2021-11-24 at 18:25 +0800, Tzung-Bi Shih wrote: > > > On Wed, Nov 24, 2021 at 04:45:13PM +0800, allen-kh.cheng wrote: > > > > > +static int mtk_adsp_mbox_send_data(struct mbox_chan *chan, > > > void > > > > > *data) > > > > > +{ > > > > > + struct adsp_mbox_ch_info *ch_info = chan->con_priv; > > > > > + void __iomem *reg = ch_info->va_reg; > > > > > + > > > > > + spin_lock(&ch_info->lock); > > > > > + writel(ch_info->ipc_op_val, reg + MTK_ADSP_MBOX_IN_CMD); > > > > > + spin_unlock(&ch_info->lock); > > > > > > > > Why does it need the lock? > > > > > > Is the write to MTK_ADSP_MBOX_IN_CMD a synchronous operation? > > > - If yes, I failed to understand why does it need the lock. Every > > > calls to mtk_adsp_mbox_send_data() should wait for the data > > transfer > > > completion. > > > - If no, I also failed to understand > > why. mtk_adsp_mbox_send_data() > > > has no way to be aware of the transfer completion. Would expect a > > > loop for checking the completion for the case. > > > > > > > In ADSP MBOX IPC flow, > > Host would call mbox send data when the shared data transfer completed. > > (mtk_adsp_mbox_send_data will notice client using MTK_ADSP_MBOX_IN_CMD) > > It’s more like a signal. > > In general case, > > There may be some hosts use the same mbox channel. > > I think it’s better using lock to protect access to > MTK_ADSP_MBOX_IN_CMD registers I still failed to understand. What if 2 hosts notify the same client by writing MTK_ADSP_MBOX_IN_CMD at the same time?