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 B6F02C2BA15 for ; Mon, 17 Jun 2024 13:28:31 +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=UDBscW4owrDj0e7q3uYOnR+K0qA6EUThSsmJJ3vZwgg=; b=LvVvdEG68VpAr5EFGe+hiGDh4j CQqdRsZcpuhiv0L4xi6x54F4vCHkdcmKh8YdeGwqDqGxUUbZ322seNbHVzOdJA8gMAoR79psLXqk9 s4PSeOwemKX/4UosqRKOfhMYCr3/pwxD5TEQMQXIYedF4A3yeW4e1R+I/88I8m82xA5OCGJjYzwIY XLyG2Cgcy7spn1Cwll62lvVw8/bCQ4r4pl2Dwj/ln4waRvc8KDBfsMIqHxfLALppoD2bGXnevMrx6 cSJy1NgCJY9X/sh/kB0Tx6V17a6chektuAHvYmZc0t2dEUKY88b33RsjZjfcxcbPcD4TpTCCP2HWr YkQjPzCw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJCPE-0000000AqqO-1r2w; Mon, 17 Jun 2024 13:28:20 +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 1sJCPB-0000000AqpE-0jeE for linux-arm-kernel@lists.infradead.org; Mon, 17 Jun 2024 13:28:18 +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 40D62DA7; Mon, 17 Jun 2024 06:28:40 -0700 (PDT) Received: from bogus (unknown [10.57.90.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3C83E3F64C; Mon, 17 Jun 2024 06:28:14 -0700 (PDT) Date: Mon, 17 Jun 2024 14:28:11 +0100 From: Sudeep Holla To: Peng Fan Cc: "cristian.marussi@arm.com" , "robh@kernel.org" , Krzysztof Kozlowski , Conor Dooley , Sudeep Holla , "arm-scmi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: scmi mailbox max_rx_timeout_ms value Message-ID: <20240617132811.adcqbpf5u7e4xqe7@bogus> References: 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-20240617_062817_317376_BF43546E X-CRM114-Status: GOOD ( 14.13 ) 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 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 > 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. > So I am thinking to use a device tree property for this, saying > "mbox-rx-timeout-us", just as "atomic-threshold-us" in arm,scmi.yaml > May be, I am not completely against it as we need this if some platforms need say 50ms instead of 30ms. Typically any sync command needs to be processed with few 100s of uS not even as high as a mS. So as I said before 1000mS needs lot of convincing. I am not even sure of 1s is tolerable latency in general for some of the SCMI perf commands. -- Regards, Sudeep