From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1D35B268C5B; Thu, 13 Mar 2025 15:09:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741878594; cv=none; b=ljAk43PiKhhzAw/E4BffHs53HTCmUGzWozwXHbWKJEwwoinTOFajKFukLkSnu+8LbnZ3SwBA+kCMxLW5NPaZ4YPLJPFHsK3UvaaV4kuOMEBKqAz7sDMqHxo18IiNpAE2kVjuf470wgDMXLIVrlpg1cvMhuHew2ovol2dkIQbhPE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741878594; c=relaxed/simple; bh=+iiUyL202c0si2LthRlsePbrvSQoTqyqBToD03RD0Hk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Zw9M9BNLF3OJ+icequMHYtOlFqorjKD30J0yAfTkFqfwGm/HLBXQRBrw6zCsBygkTzcN5bsUT1wmRt8JK4pVgJ3DP0mLXgLOsL4D4vmdz1azebjbfdC17/+o3kGbxxIaltUiRLL02uUtpxxsNP2nxjYZjQIxm+bp0b2gm0dzjOs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com; spf=none smtp.mailfrom=foss.arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=foss.arm.com 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 7C940113E; Thu, 13 Mar 2025 08:10:02 -0700 (PDT) Received: from bogus (e133711.arm.com [10.1.196.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D48BB3F694; Thu, 13 Mar 2025 08:09:50 -0700 (PDT) Date: Thu, 13 Mar 2025 15:09:48 +0000 From: Sudeep Holla To: Robbie King Cc: , , Jassi Brar , Sudeep Holla , Huisong Li , Adam Young Subject: Re: [PATCH v2 02/13] mailbox: pcc: Always clear the platform ack interrupt first Message-ID: References: <20250305-pcc_fixes_updates-v2-0-1b1822bc8746@arm.com> <20250305-pcc_fixes_updates-v2-2-1b1822bc8746@arm.com> <4ef4df06-c6f8-4151-96e1-78be58f32f54@xsightlabs.com> Precedence: bulk X-Mailing-List: linux-acpi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ef4df06-c6f8-4151-96e1-78be58f32f54@xsightlabs.com> On Thu, Mar 13, 2025 at 11:08:04AM -0400, Robbie King wrote: > On 3/5/2025 11:38 AM, Sudeep Holla wrote: > > The PCC mailbox interrupt handler (pcc_mbox_irq()) currently checks > > for command completion flags and any error status before clearing the > > interrupt. > > > > The below sequence highlights an issue in the handling of PCC mailbox > > interrupts, specifically when dealing with doorbell notifications and > > acknowledgment between the OSPM and the platform where type3 and type4 > > channels are sharing the interrupt. > > > > ------------------------------------------------------------------------- > > | T | Platform Firmware | OSPM/Linux PCC driver | > > |---|---------------------------------|---------------------------------| > > | 1 | | Build message in shmem | > > | 2 | | Ring Type3 chan doorbell | > > | 3 | Receives the doorbell interrupt | | > > | 4 | Process the message from OSPM | | > > | 5 | Build response for the message | | > > | 6 | Ring Platform ACK interrupt on | | > > | | Type3 chan to OSPM | Received the interrupt | > > | 7 | Build Notification in Type4 Chan| | > > | 8 | | Start processing interrupt in | > > | | | pcc_mbox_irq() handler | > > | 9 | | Enter PCC handler for Type4 chan| > > |10 | | Check command complete cleared | > > |11 | | Read the notification | > > |12 | | Clear Platform ACK interrupt | > > | | No effect from the previous step yet as the Platform ACK | > > | | interrupt has not yet been triggered for this channel | > > |13 | Ring Platform ACK interrupt on | | > > | | Type4 chan to OSPM | | > > |14 | | Enter PCC handler for Type3 chan| > > |15 | | Command complete is set. | > > |16 | | Read the response. | > > |17 | | Clear Platform ACK interrupt | > > |18 | | Leave PCC handler for Type3 | > > |19 | | Leave pcc_mbox_irq() handler | > > |20 | | Re-enter pcc_mbox_irq() handler | > > |21 | | Enter PCC handler for Type4 chan| > > |22 | | Leave PCC handler for Type4 chan| > > |23 | | Enter PCC handler for Type3 chan| > > |24 | | Leave PCC handler for Type3 chan| > > |25 | | Leave pcc_mbox_irq() handler | > > ------------------------------------------------------------------------- > > > > The key issue occurs when OSPM tries to acknowledge platform ack > > interrupt for a notification which is ready to be read and processed > > but the interrupt itself is not yet triggered by the platform. > > > > This ineffective acknowledgment leads to an issue later in time where > > the interrupt remains pending as we exit the interrupt handler without > > clearing the platform ack interrupt as there is no pending response or > > notification. The interrupt acknowledgment order is incorrect. > > > > To resolve this issue, the platform acknowledgment interrupt should > > always be cleared before processing the interrupt for any notifications > > or response. > > > > Reported-by: Robbie King > > Reviewed-by: Huisong Li > > Signed-off-by: Sudeep Holla > > Tested-by: Robbie King > Thanks Robbie for reporting the issue and testing the fix. Much appreciated! -- Regards, Sudeep