Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp556269pxv; Wed, 14 Jul 2021 09:56:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZ/shsZ9TVPqjYTuAdTLmX/Q5KeCD8GtYNE7e06vJq3tueSypLxCdfLXXrX3JSS9Bd7xUX X-Received: by 2002:a17:906:c13:: with SMTP id s19mr13428410ejf.439.1626281780707; Wed, 14 Jul 2021 09:56:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626281780; cv=none; d=google.com; s=arc-20160816; b=ZICXtOdPcO3KKYgA0pLj9MklDErYW1k7gH9hrn/3t5KSBbjv5hnkP+Bx2nNwZmWGHC e5ezY05UKUnZlBjSKO1WZFZwTnOj5LxgYlbQUxAKd02syhSobdl1WP34sFurmz2z6yLg xD0IESFDjK3dt0t2ZBVSg8l8YDG4f6vm3k7wZwu4QcQuhvVR6EYOKp8wAWwFRnK30WDF UhIw+XZLjA16IMntcf30K237Hr8wCRFEjeTXE2/jJ83kjaJN46t76dAi90Whd/dFeW6G yt/NT8bBiTVhT2uVYJiBo2ICVcRFdcKnW4n1ZdFoX7nl9nKqXAgg4bLhVU9Pt5gtdxga kcng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=WEckHeiemG8sJmvDu0M7HI7AiSRTfleIcmFpISXK/XI=; b=mDQWlU+IqUYg3Td+VAqgdCrm6V0aO69Q3BtfJw8eBceOh3yFMJZW37cWh1nnThEO8g CztsrIa47gVQ0tWR2gV7Nq74HfUySKXxwVdICUeok2WWKNG8WPb3YDULr28jEeR42ThK a8OypUy7The9QixacnIKR7r5Drqz6I3yhU9+uHSH2JDvPs8nFsx1DCG+GmfQQH5Nng4/ IT9b7RIALUKaR92eg866F/pK3pUUtnYkTz4U9rDb3B77J0WufHp2Aj3du/QBli0RO7sZ Y7yuQnnFJkL5JXTPWsNwbO7ddDDz7SYX+jVBJBDd4tdcbRDnJVU0QlnLca2g7wmgfkgY pGiQ== 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 b1si3326065edx.272.2021.07.14.09.55.56; Wed, 14 Jul 2021 09:56:20 -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 S236038AbhGNQ5b (ORCPT + 99 others); Wed, 14 Jul 2021 12:57:31 -0400 Received: from foss.arm.com ([217.140.110.172]:37166 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235859AbhGNQ5b (ORCPT ); Wed, 14 Jul 2021 12:57:31 -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 60CBED6E; Wed, 14 Jul 2021 09:54:39 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 811A13F774; Wed, 14 Jul 2021 09:54:37 -0700 (PDT) Date: Wed, 14 Jul 2021 17:54:34 +0100 From: Cristian Marussi To: Sudeep Holla Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, "Rafael J . Wysocki" , Jassi Brar Subject: Re: [PATCH 03/13] mailbox: pcc: Refactor all PCC channel information into a structure Message-ID: <20210714165434.GC6592@e120937-lin> References: <20210708180851.2311192-1-sudeep.holla@arm.com> <20210708180851.2311192-4-sudeep.holla@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210708180851.2311192-4-sudeep.holla@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 08, 2021 at 07:08:41PM +0100, Sudeep Holla wrote: > Currently all the PCC channel specific information are stored/maintained > in global individual arrays for each of those information. It is not > scalable and not clean if we have to stash more channel specific > information. Couple of reasons to stash more information are to extend > the support to Type 3/4 PCCT subspace and also to avoid accessing the > PCCT table entries themselves each time we need the information. > > This patch moves all those PCC channel specific information into a > separate structure pcc_chan_info. > > Signed-off-by: Sudeep Holla > --- Hi Sudeep, > drivers/mailbox/pcc.c | 106 +++++++++++++++++++++--------------------- > 1 file changed, 53 insertions(+), 53 deletions(-) > > diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c > index 23391e224a68..c5f481a615b0 100644 > --- a/drivers/mailbox/pcc.c > +++ b/drivers/mailbox/pcc.c > @@ -64,12 +64,20 @@ > > static struct mbox_chan *pcc_mbox_channels; > > -/* Array of cached virtual address for doorbell registers */ > -static void __iomem **pcc_doorbell_vaddr; > -/* Array of cached virtual address for doorbell ack registers */ > -static void __iomem **pcc_doorbell_ack_vaddr; > -/* Array of doorbell interrupts */ > -static int *pcc_doorbell_irq; > +/** > + * struct pcc_chan_info - PCC channel specific information > + * > + * @db_vaddr: cached virtual address for doorbell register > + * @db_ack_vaddr: cached virtual address for doorbell ack register > + * @db_irq: doorbell interrupt > + */ > +struct pcc_chan_info { > + void __iomem *db_vaddr; > + void __iomem *db_ack_vaddr; > + int db_irq; > +}; Given that this db_irq represents the optional completion interrupt that is used platform-->OSPM to signal command completions and/or notifications/ delayed_responses and it is mentioned indeed in ACPI 6.4 as "Platform Interrupt" and also referred in this driver as such somewherelse, is it not misleading to call it then here "doorbell interrupt" since the "doorbell" in this context is usually the interrupt that goes the other way around OSPM-->Platform and is indeed handled by a different set of dedicated Doorbell registers ? (that are indeed called Doorbell throughout this driver down below ...but I understand this was the nomenclature used also before in this driver) Thanks, Cristian