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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 08A26C27C4F for ; Tue, 18 Jun 2024 10:07:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=u3GLMCusiXHyVebrU0yVWCUKnw9picRR0JCG7ikSpsk=; b=RLerF9kc6VvZqGjWrf41z8H0ct AURNikQUR9Ezik2RU/LbZWl4YnE/7uZ1wpcCjeKFfmRXeKUTuVb0MS0MIJVc2jSQoWq4wVBvlbQLD SC6jKR/uXZD8px2AS/5qWio4vTyZgFQSg3FzhZNBMjb5/VfblOGqbBlJQVzmuCq3nrKBXjAzW35Qs xN2nk/UjBYIft4GBd7FJsKoshDboY3KlgMpyG7jpBUET8+v2yfJIuBLJtv9l+hVtHEQl55ln1S67q GGR+aHLMvgW3JBYC6trQ+YjfyBShiwgWC1dWqqehVT7CqO4NMmz7vtFpd/m1/2p+krtIepIHUsGrY G6WeMGOQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJVkL-0000000EGKV-24DK; Tue, 18 Jun 2024 10:07:25 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJVkH-0000000EGJE-0z4V for linux-arm-kernel@lists.infradead.org; Tue, 18 Jun 2024 10:07:23 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8E191DA7; Tue, 18 Jun 2024 03:07:44 -0700 (PDT) Received: from bogus (unknown [10.57.89.235]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 242E13F6A8; Tue, 18 Jun 2024 03:07:18 -0700 (PDT) Date: Tue, 18 Jun 2024 11:07:16 +0100 From: Sudeep Holla To: Peng Fan Cc: "cristian.marussi@arm.com" , Sudeep Holla , "robh@kernel.org" , Krzysztof Kozlowski , Conor Dooley , "arm-scmi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: scmi mailbox max_rx_timeout_ms value Message-ID: <20240618100716.wlgf4wc6afzjlutu@bogus> References: <20240617132811.adcqbpf5u7e4xqe7@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240618_030721_857518_548A554E X-CRM114-Status: GOOD ( 25.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 18, 2024 at 02:12:06AM +0000, Peng Fan wrote: > > Subject: Re: scmi mailbox max_rx_timeout_ms value > > > > On Mon, Jun 17, 2024 at 09:17:11AM +0000, Peng Fan wrote: > > > Hi Sudeep, Cristian and DT maintainers > > > > > > In drivers/firmware/arm_scmi/mailbox.c, current > > max_rx_timeout_ms is > > > 30ms, we wanna to enlarge the value. > > > > Care to provide the reason for the same ? Few possible bottle- > > neck/issues: > > 1. Transport > > 2. Firmware implementation > > 3. Processing capability of co-processor implementing SCMI > > We have M7 and A55 and even more SCMI agents in future, > A55 linux agent has the lowest priority. > > In normal case, we not see issue using 30ms, but in extreme > corner case, A55 linux may not get response in long time > if other higher priority agents have heavy SCMI requests. > > > > > > NXP downstream value is set to 1000ms, but for upstream I think it > > may > > > not be a good solution that just enlarge it for all scmi users, > > > > I think it may not be good solution on any modern platform to have > > such high latency for P2A or A2P communication. Even Juno(a decade > > old platform copes well with 30ms with SCP running at 50MHz(IIRC). So > > I am interesting in getting more info about i.MX before we can decide > > on the right path to progress here. > > > > > Each platform may have its own max timeout value depends on scmi > > > firmware design. > > > > Fair enough, but 30ms to 1000ms just seems wrong to me to start with. > > I simple need more information to get convinced here. > > It is just based on i.MX8QM/QXP SCU experience. We thought 30ms > might be not enough, so chose a large value 1s here. Well why 1s ? Why not 100ms or 50ms or 200ms ? 30ms was initially set as mailbox initially didn't use HR timers and we wanted to set at least 2-3 jiffies on a 100 HZ system. It can be and must be lower than that but left it there as worst case value. So can you elaborate as how slow A55 and M7 can run and why 1s is good and right choice ? Coz we may have to see if perf fast switch needs to be disabled if fast channels are not supported ? It may have other implications. It can't be just any random number like 1s as some developer felt like testing to overcome the issues seen on this platform. -- Regards, Sudeep