Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp399212pxv; Thu, 15 Jul 2021 06:54:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyzOsgv7tlW8+E7jrDGtNYlaSUWYroDnNYiuXlJD82H5ag/UGWKeRMFZlfebDffjJjBTC3l X-Received: by 2002:a05:6402:152:: with SMTP id s18mr7176505edu.221.1626357292375; Thu, 15 Jul 2021 06:54:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626357292; cv=none; d=google.com; s=arc-20160816; b=giTewtyMDNvzHWz5kcaQWDS1SnSwP36c8SEtbG8i4EyXnd6GkASf2dlZma1vpcJb9a hz2yD3r0Qj25AgrDPSOk4GIGSzM519hv7l9R4nIqtwjJwWpVx+IaT/IcgfWzFb7M3NMj +C8VdUhuG4nDo1fX4YzlR+ovFnJZvODWkj/E1mmWCVGHfjRQkJnHyOkMuswe/6bvOeme JnAuKLS7BLVloWooKmJcYQS+FJNUsaDsxCa38CLJqZk5KDRLM3scrORmcAbwSlSVQmak ZVN03Y21peDkxCeTVQicJJXOqnCkieyNj/H8szl56oB1l7kww4q9rU096LeZ5TBm4BtP AZjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=dirCwyAWiqsEEckXIRlvevBWOOsRyEm3dndDgyI7AFA=; b=iZltvYXuYKWq4JzH4EnVQ+lRcn9qGu5KhPHs03yhhjc5Q9HPaf4uqULy4mZ0Dx7nTv 8jelijwn+/pJjH1l44+sD32WKLfzx6KyaMjYVoMV38RnfiSXAOi2nRO6JpU5lYACFZ/F 8LUCQoKTObzdufN2YnIXRaUsrTcyg5VY5xLAK3oFoJLfH3Z2HqKZ5/lx8orOV9c10phy rw0NcE2k9KDiTUsai9NWpVA2gi74gp7YuO6dmHgi25rWC2s6ZebcYVAXEmxV9O9igsaW rr2YjPglug1ZJ1mUr9VCyoq0N1phWZ9jrjSUTtiHu1AnWNwwZtNau/667mBrn0d3GvfK I91A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d21si7216028ejt.443.2021.07.15.06.54.29; Thu, 15 Jul 2021 06:54:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241996AbhGOLe6 (ORCPT + 99 others); Thu, 15 Jul 2021 07:34:58 -0400 Received: from foss.arm.com ([217.140.110.172]:51430 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241993AbhGOLe4 (ORCPT ); Thu, 15 Jul 2021 07:34:56 -0400 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 0AC4C31B; Thu, 15 Jul 2021 04:32:03 -0700 (PDT) Received: from bogus (unknown [10.57.79.213]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A86BA3F694; Thu, 15 Jul 2021 04:32:01 -0700 (PDT) Date: Thu, 15 Jul 2021 12:31:02 +0100 From: Sudeep Holla To: Cristian Marussi Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, "Rafael J . Wysocki" , Sudeep Holla , Jassi Brar Subject: Re: [PATCH 12/13] mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4) Message-ID: <20210715113102.oww24dj73fq2imbl@bogus> References: <20210708180851.2311192-1-sudeep.holla@arm.com> <20210708180851.2311192-13-sudeep.holla@arm.com> <20210714185216.GE49078@e120937-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210714185216.GE49078@e120937-lin> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 14, 2021 at 07:52:16PM +0100, Cristian Marussi wrote: > On Thu, Jul 08, 2021 at 07:08:50PM +0100, Sudeep Holla wrote: > > With all the plumbing in place to avoid accessing PCCT type and other > > fields directly from the PCCT table all the time, let us now add the > > support for extended PCC subspaces(type 3 and 4). > > > > Signed-off-by: Sudeep Holla > > --- > > Hi Sudeep, > > just a few general observation on Type 3/4 subspaces from the spec > Table 14.7: > > - "If a slave-subspace is present in the PCCT, then the platform interrupt flag must be set to 1." table 14.7 > > Maybe is worth to WARN on this if this assumption is violated by the > ACPI table we found. > > - "Note that if interrupts are edge triggered, then each subspace must have its own unique interrupt." > > Same here, maybe it's worth also to check this, so that after all the > pchan->db_irq has been obtained no edge triggered irqs are duplicated > before requesting them. > Both valid points and in my TODO list, just forgot to address this as I didn't have a setup to check/flag these up. I will address them in next version. Thanks for reviewing these patches. -- Regards, Sudeep