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 X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79D9EC11F66 for ; Wed, 14 Jul 2021 16:54:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 68DF261154 for ; Wed, 14 Jul 2021 16:54:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236312AbhGNQ5c (ORCPT ); Wed, 14 Jul 2021 12:57:32 -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