Received-SPF: pass (google.com: domain of linux-kernel+bounces-93666-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Wed, 6 Mar 2024 09:49:11 +0000
From: Cristian Marussi <cristian.marussi@arm.com>
To: Flash Liu =?utf-8?B?KOWKieeCs+WCsyk=?= <Flash.Liu@mediatek.com>
Cc: "linux-mediatek@lists.infradead.org" <linux-mediatek@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	wsd_upstream <wsd_upstream@mediatek.com>,
	Cylen Yao =?utf-8?B?KOWnmueri+S4iSk=?= <cylen.yao@mediatek.com>,
	"sudeep.holla@arm.com" <sudeep.holla@arm.com>,
	"linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"angelogioacchino.delregno@collabora.com" <angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH v2] firmware: arm_scmi: Avoid to call mbox_client_txdone
 on txdone_irq mode
Message-ID: <Zeg8F6VVaZtpmH8n@pluto>
References: <20240201095754.25374-1-flash.liu@mediatek.com>
 <ZbzKckIhn8HQv5pW@pluto>
 <053cb4a2edfe576412942daed2f7055b2ba9e207.camel@mediatek.com>
 <56e1b2f5adbca437a14b738e1c58a054f6302fcd.camel@mediatek.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <56e1b2f5adbca437a14b738e1c58a054f6302fcd.camel@mediatek.com>

On Wed, Mar 06, 2024 at 06:13:48AM +0000, Flash Liu (劉炳傳) wrote:
> Hi Cristian,
> 
> Kindly ping :)
> 

Hi Pin-Chuan,

sorry for the delay...I have NOT forgot :D, indeed I was just testing
yesterday with some mailbox IP of ours equipped with a TxAck IRQ and I
would have some question for you because I've seen some anomalies while
using this: does your solution work reliably in your setup ALSO when
multiple SCMI transactions are attempted ? (like cpufreq issuing cmds
while polling a sensor from some other thread)

..I'll dig deeper today in this matter, but my current suspect is that
using the mailbox TXAck IRQ to let the controller tick the internal mailbox
queues does not play well with SCMI, since the SCMI TX channel is really the
SCMI "a2p" bidirectional channel and it is associated with just only one shmem
area used to hold both the egressing CMD and to receive the incoming REPLY
from the platform: so if you let the controller tick the queues as soon as you
received the TXAck you are telling the mailbox subsystem to queue another message
on the same area while you are not really done, since only the client know
when it's done with the whole SCMI transaction and the reply has been fetched.

Indeed, for these reasons we have the BUSY/FREE bit in the shmem to protect it
from pending new requests until the previous one has completed, but when the
waited-for reply comes in, the platform would have cleared the BUSY bit and
let the new queued message overwrite the pending reply prematurely, and one
message is lost...

..but as said I want to delve deeper into this, as of now just suppositions
and maybe I am just missing something more that has to be configured
properly...

Thanks,
Cristian

> Thanks.
> Pin-Chuan
> 
> On Fri, 2024-02-02 at 20:36 +0800, Pin-Chuan Liu wrote:
> > Hi Cristian,
> >
> > Thanks for kindly review and explains. Yeah, I have ever tried
> > another
> > way to skip the call (i.e. let mark_txdone be null). However, it
> > looks
> > not easy and also to backport.
> >
> > Awaiting your test results and further suggestions, thanks.
> >
> > Regards,
> > Pin-Chuan
> >
> 
> 
> ************* MEDIATEK Confidentiality Notice ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!