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 39FB3C04FFE for ; Wed, 8 May 2024 17:04:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=chsXbV6RHVFQuoWlcauvomkiDZwiu8sv7eWzSgTa2Ss=; b=TLTJhzVaWlEfC1 c6utVnLci4JTc8fSadqZWzSB9K95miHwSTe0PzAUgmEi3wQntpMOoSE+n5YSy9C23wlGBGF2WOYyl S3Kz4sm0jwb9wERQLtxkLEJ5BpMxBvIPLI+lljnnKxVAQfasjq5d5gJ+gVeA4PDPVyoPrE6Y07qJN ETIw1To2CZkXdJkKRL8G0ZzW7rBwX6KnSTaEwQ0Vmqm1jO3UeBU+qBV9IsDOt37T85ersA33lqxO+ d/3WEX3+pQh+KcJA4dMgohwIs2M/JQTdRNAGTAXSge2GcUQxDdYZiqaisweEfEYONpDDXx5oDNsOL WAYQRZbxxMZuzXS3ZdrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s4kiN-0000000GHBp-2EaE; Wed, 08 May 2024 17:04:23 +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 1s4kiF-0000000GH4d-3PEb for linux-arm-kernel@lists.infradead.org; Wed, 08 May 2024 17:04:20 +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 856B81007; Wed, 8 May 2024 10:04:30 -0700 (PDT) Received: from pluto (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4B8933F6A8; Wed, 8 May 2024 10:04:03 -0700 (PDT) Date: Wed, 8 May 2024 18:04:00 +0100 From: Cristian Marussi To: "Peng Fan (OSS)" Cc: Sudeep Holla , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Peng Fan Subject: Re: [PATCH 0/2] firmware: arm_scmi: add notification completion channel Message-ID: References: <20240507-scmi-notify-v1-0-1fdefc984d53@nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240507-scmi-notify-v1-0-1fdefc984d53@nxp.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240508_100415_906194_BC96CAE8 X-CRM114-Status: GOOD ( 16.71 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 07, 2024 at 11:34:59PM +0800, Peng Fan (OSS) wrote: > Per spec: Hi Peng, thanks for doing this. > Completion interrupts This transport supports polling or interrupt driven > modes of communication. In interrupt mode, when the callee completes > processing a message, it raises an interrupt to the caller. Hardware > support for completion interrupts is optional. > > i.MX95 SCMI firmware is fully interrupt driven, so Platform expects > completion interrupt for Platform to Agent(P2A) notifictions. > > Add another optional mailbox channel for Agent to notify Platform that > notification message has been accepted > > After notification channel status become freed, Agent will use the > new mailbox channel to send completion interrupt to Platform. > > Add shmem_channel_intr_enabled to check channel flags. Glancing through the series I think the bindings and the code are quite good and sensible to achieve the addition of the optional P2A completion interrupt. Your current solution, though, addresses only the case of a mailbox controller providing unidirectional channels. (which I suppose is the one you are using on your platform) We should take care to add such optional P2A completion interrupt support also for the case of mailboxes sporting bidirectional channels. For bidirectional channels we really have already the needed bindings... ...no changes there...you have just to also ring the doorbell on that same P2A if completion IRQs are requested. IOW, when the DT description is made by 2 mboxes + 2 shmem, means we have both A2P and P2A provided via bidirectional channels...we currently just use the P2A (RX) channel to receive notifs/dresp via rx_callback (so using only the platform_to_agent direction)...now we should also ring the P2A doorbell on the existing P2A channel if the FLAG_INTR_ENABLED is set to signal the completion interrupt on the other direction (agent_to_platform) Not sure if I have been clear or make it worst with my explanation :P Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel