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 EA316C433EF for ; Tue, 19 Apr 2022 23:07:02 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: 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=s5ROUJJp7N49koH3bCaDoMhHgT0r5LUik607xi6jPPM=; b=fsx+50cbPmsxIZZW4o4Spm8x86 NcDsXbN/REazIrUSNr/MpBrh/a1vtZ52EZymW/Que/+Q5AGlw0Z7QcXiegjJFWrrDhthAsbbYBJry fOTONL7DCa++z05cSqHn85h1U7BD55y/NhEBqcutzZQOmcVtTBXm7TZwtfb+Lu91kp/SFfzG0Ioro CXufqTB1i83+WslL6yqD9A2tdw9S1BARISi4136V52AFQnazFmkNcXfnRs7OFLAmnVeAbUsu7tftT HhaisA+GIZ/QyPT7fO1MJ9ltjsFGhdbsF01h6i74SeIQVGKsMnLVQxrieM4mwscXFf0sXgL6jGllm waca9KzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ngwut-006bPO-27; Tue, 19 Apr 2022 23:05:51 +0000 Received: from mail-dm6nam08on20724.outbound.protection.outlook.com ([2a01:111:f400:7e8b::724] helo=NAM04-DM6-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ngwup-006bOs-KU for linux-arm-kernel@lists.infradead.org; Tue, 19 Apr 2022 23:05:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g2Zo2S7bvzTfY8Gyvq0cF4VQ02dV5RisxjrVjHKswkgxpMAUu57b4BrbAYA9UGrC9SygQEuiT0E09DYPJ0Gaz/5zCjesmzsdLA9COjQ9xt928hVtTpcUi/SbKaBp1LRcugDCFM3QCa+lj7YHYKbV152COxMOSNAKNEZMok9GN6nUzEgRO/Svt4g5C3fYKtSsBMXBRpCuFEbrcdOoc8RgN3A2YfnlELckCizvOu8ijV7tYHUB8RelsmsaRyoagkdf1Eb9pMcrmyo+b8pKOVAh9BuiFpbdYVcmpnIWnpyAOlp/93EZZ9qRdWfJ0qUuZsuHVqZYlnhYpxCGUTJrWAUu6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=F1GvrgnncRoBs0R5xguX/0hPlN4BIXmOEkRVxcwYgfg=; b=NAvdC3P75QZZfnmXG1+ERkOeV/k8o9079XgSgz1tqykXFv7A9/QLFpYvH7pxCiYvbesDG6DVLSaYT2vsmVYQ/tWqjq7GRQqgkX5o1EVRpLLiXm5TCNqzyOjC+I7ft91fNCpQsUNR8ieAXbVp27tBMoFrGbKsHQYiTgzTIF6JgOClrot7gqQ0I0fu5MU9nSohz525H/PO3URTxuCzaPdVQJjVHjEQQSVZd/d38iu3LCMZ1wNsRZl7LJYZgjK4f41yoW/V1RIh7QWD8lgipEIxejR8Pn+on0daiZtc6pl5O7ghkSrkNE7XkyH3H5ilgtgNFzy1uMY7qKP4iYKJxsDRcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=os.amperecomputing.com; dmarc=pass action=none header.from=os.amperecomputing.com; dkim=pass header.d=os.amperecomputing.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=os.amperecomputing.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F1GvrgnncRoBs0R5xguX/0hPlN4BIXmOEkRVxcwYgfg=; b=HAlNw/cOkMfZ65v6MP0ijAnQ5BOXbQHc64dABQxuVWqk4NMWWLK5L/XWh6HKAFw7rlPa7A5NKZx4OM1NByM2/nmZBRBEfINNKV1wMWWgYwFMiIk1UoWlFBeyCNf3UMIfa+kJvSZM5VCIqIfjycsbEoGVuzpaINf2zPmNN4pEjoo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=os.amperecomputing.com; Received: from DM5PR0102MB3590.prod.exchangelabs.com (2603:10b6:4:a4::25) by SN6PR0102MB3501.prod.exchangelabs.com (2603:10b6:805:3::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Tue, 19 Apr 2022 23:05:41 +0000 Received: from DM5PR0102MB3590.prod.exchangelabs.com ([fe80::5015:1ef4:46b6:5b34]) by DM5PR0102MB3590.prod.exchangelabs.com ([fe80::5015:1ef4:46b6:5b34%7]) with mapi id 15.20.5164.025; Tue, 19 Apr 2022 23:05:40 +0000 Date: Tue, 19 Apr 2022 16:05:19 -0700 (PDT) From: Ilkka Koskinen X-X-Sender: ikoskine@ubuntu200401 To: Robin Murphy cc: will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/4] perf/arm-cmn: Add CMN-650 support In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) X-ClientProxiedBy: MW4PR03CA0109.namprd03.prod.outlook.com (2603:10b6:303:b7::24) To DM5PR0102MB3590.prod.exchangelabs.com (2603:10b6:4:a4::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fdf25cf2-6f76-49de-d574-08da22591f24 X-MS-TrafficTypeDiagnostic: SN6PR0102MB3501:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CoNkdz1PvBuKwo9q/nA2+j2J5nMQ6YA5GkHexCmQdRrQlmwL+OLNpNsVoYWsOui+X2wrfObDT96bW3xfOE7dLWfKw6NI2SY0lgYGHWq0Cae0RxoPOg9lmYthCXYBSns7/GpXxEpXGIDvCYHn9LgIb1XrEe1fL6Y5XNKYmQy5CKnJKOQV37dmJni1j42CPgP03jZsNEKNFhuXeQlwwzBqbGKirtimwStM93OIqiqsVSzUiNSAUV5HVY4AW/OeA6lathG+DFKMVDGSlQUIkmUvP7fdms7wBq6v3kvLPB0wmrjQ0JhXfEZ+/hCfmZMO8rB9G/c2dXyc6fbtB5Fm9fXwrduZjDHSbgoqu/SFKOennbmrcqd9f1Ey/UJyolCKjEmC789b/QahbquTRAp4CuEXoxKCaCnzlRSR8sRWn7FcuJ1LLNUNZ9psC2WYSayHkNUOwZ+PP0I1JXzc0Q8nXMgFYTaB3/ERHsLy9OzFTj58JwGwch8oGjYS1xgyvvy8Sr95tBai9iMtJoDaCeAbOSH/q6fKcJo2m88JjCyehwthUcIP/SItqNy5uPrYt+S12cIkIOnaEnPjiYnG4P2QH2dc9eV04ofBT03y2yShzwDMSnRx+j7GXsykRlZsWP+FzNaxMJhN20/e0yavnkGmjNfgTYeCYvk/NykN+XGiGyAM37U8nK0l7EUT6U9dHV5hFCCsRyVDi7DPze2YqeLbtxigQg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0102MB3590.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(7916004)(366004)(6506007)(5660300002)(52116002)(2906002)(6486002)(6666004)(6512007)(9686003)(26005)(508600001)(186003)(8936002)(316002)(86362001)(4326008)(33716001)(6916009)(38100700002)(38350700002)(66946007)(66556008)(83380400001)(66476007)(8676002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?6F4HCIwQlNWD8gwjOSTm4oNuxNbtDq9p2qNJJt6HqvEK8PgIO5VgUH0ZTDUO?= =?us-ascii?Q?4/mx66YI7aLd9P3e+OWKkxRcu9Tb0HtFHCHd8QFvvJnGhzh0fB5sReINUbYp?= =?us-ascii?Q?G9aBIFTrmF2IjRmmn7Lrc1gM3inV4yMKILU6H2cPZvYZsYp4tCysAol86awD?= =?us-ascii?Q?LHeD8xGiDrZhDOBiysqKgLPTgsQVTUg+AYb1Y8Nvhv5ajfujv5oAYdJYZBhD?= =?us-ascii?Q?spnrD8dUinbnqXCLIEciVG9WsYXq7LZMKMzLb44SHMowy51tLo6xOjh2lEDZ?= =?us-ascii?Q?xzAgQjbE542HsUqsbF1Id1kq1flAWXgYxCQfHLAaZC0WIfxiazKmeXicADkb?= =?us-ascii?Q?JT/DfwKF0nSOOU6xW9ytgWz7GDkueh/SM8GKwSPECvhAvonblTSiR+aFxr58?= =?us-ascii?Q?rMGtfBHf9ykr3XzZbU+noogN4cLMQ+doQLjT8O6T2EsotONWt6TWeiDw7xN3?= =?us-ascii?Q?KXD/3aVWhOZDpGLD0waPOVYSIqoC8GLXuA5RaMreWtIavMEhnGT2cPC7b421?= =?us-ascii?Q?LCASk2h2DEtbo4CGGgH5g7Zd8EXifmX0Z3a3SyGvAa4dO4NadTON010NCCev?= =?us-ascii?Q?36DdS/MyMILQbwjTRGCTTO0ibhT54y4AWD7Jgd/f7h6GeCyCf+O/ZRDMY1Ea?= =?us-ascii?Q?YQ55wVUX1HVspDHIlWpk8eGf5fzJZBa4qgj2qBDhrUnHDc1/qHXxxstY/WHG?= =?us-ascii?Q?SDMPPSiB83ipxTFUVq2+j+kvPSpcddJxTDba9IrOlA2Z1tu36/UzZUXbwfBy?= =?us-ascii?Q?wHyh2OU6eFoEMZd/CVYpqlzR7iCZnTsDZxRqpI5qhNETg7Zc4KvKwaDnqW65?= =?us-ascii?Q?WSRwvKEbbUg9mVbFv2U0pAUZFhK50+4mPBhe39UEm1MINT7ZlCf3vUtF5uKk?= =?us-ascii?Q?XEJpfayMmQs/7xE5W2PnAlLqYQDFw1SFOdrTKO7YSEbtDv24I2eNCckpm94T?= =?us-ascii?Q?UZlq+PExPDnKjLHO/ujPHYYWjqHXbafG4LIIJq8E7/3Kya+8AgfRwPSionyx?= =?us-ascii?Q?53ma4kUyYjWKhepishMMPWEoOX/MmF/ZihMp56LOnYhXpTrVA3qi855FsCtp?= =?us-ascii?Q?wfUVgVO+6lc58FvDAZVexo+LMBxPnOgeMToDTZcBh3/T9lUvZpmfUnRwbEMm?= =?us-ascii?Q?EVo7LupaC7h9u7N6fzywicNIkTDpYxLpuOmNmrTYCBMu3EWNUAPKMJnSFLtz?= =?us-ascii?Q?4OW1hi8a157qq3CWZY+DyZY2OsHir8exVPmj0TzMS2LkhZixv1vwUOb/UEqD?= =?us-ascii?Q?B4w0Z0JlUPMG+YvAfnp+qSLyi1leYZRcJE21CbsmcRGhM8YhMgdkL5T3VvFF?= =?us-ascii?Q?xnN55kypGnl1ZzL7z9uJjoMyvS1YSCPyciF/dHkZIHgXt0WByY9yIF9ZliuE?= =?us-ascii?Q?dPttivG4ipiuE/Y4V+GNGZCCjPJXqwt4flsiwrlU0vx5qc+B+bA8aBzkQHrT?= =?us-ascii?Q?+7Wlv/EU13hmh15WinrGcvsF8sGhPODh29CWLb7mDNG21QyDoZfWRG4uTu/C?= =?us-ascii?Q?EnwBTiBSnalUY5DR+61u1gFGurdAGudxgqkPwoByPHb5z4Up/xKmStqtjNAH?= =?us-ascii?Q?9i/WCxXMF3SFJbYSHJMnkvJ5mfD0cnb70CJ/g01WwW0O+eZfbCU8369w7AJO?= =?us-ascii?Q?cdlOnSvZFRnLSfKZaw28bn6wXUDz+ZcSAZ2MxnNrr6rrXtuWiU0CUgL4vJjG?= =?us-ascii?Q?8grmXxMv5eCfpmLQdJdCSd8Gbtfksc8At5/uB6wGoxyUYpwoUAaPrvXvgFr3?= =?us-ascii?Q?jShpt01Y2X6d6h6JgbmbnJG5OOWWSn/pudphio+SiKNQ2k2+L6Ie?= X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-Network-Message-Id: fdf25cf2-6f76-49de-d574-08da22591f24 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0102MB3590.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2022 23:05:39.9100 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: S2uTWWotoHdYpGO25LVRkZoctCcWBiGLUbHoI/12KcxN87MuybxQCkamuqL6QgdZiDcv8djR6X/Uh4ZPVCgtMHMSDNTbyPszm0IMSI/vhGEAlGnKpfbm4pkD/ITTgCB+ X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0102MB3501 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220419_160547_898357_735A2FEA X-CRM114-Status: GOOD ( 24.59 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Robin, I need to go through your patches more carefully, but I do have a couple of comments already: On Mon, 18 Apr 2022, Robin Murphy wrote: > Add the identifiers and events for CMN-650, which slots into its > evolutionary position between CMN-600 and the 700-series products. > Imagine CMN-600 made bigger, and with most of the rough edges smoothed > off, but that then balanced out by some bonkers PMU functionality for > the new HN-P enhancement in CMN-650r2. > > Most of the CXG events are actually common to newer revisions of CMN-600 > too, so they're arguably a little late; oh well. > > Signed-off-by: Robin Murphy > --- > drivers/perf/arm-cmn.c | 222 ++++++++++++++++++++++++++++++++--------- > 1 file changed, 176 insertions(+), 46 deletions(-) > > diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c > index 9c1d82be7a2f..cce8516d465c 100644 > --- a/drivers/perf/arm-cmn.c > +++ b/drivers/perf/arm-cmn.c > @@ -39,7 +39,7 @@ > #define CMN_CHILD_NODE_ADDR GENMASK(27, 0) > #define CMN_CHILD_NODE_EXTERNAL BIT(31) > > -#define CMN_MAX_DIMENSION 8 > +#define CMN_MAX_DIMENSION 12 I wonder if it made sense to dynamically allocate the arrays later in the code instead of allocating them in stack, especially if mesh topologies keeps growing fast. That would probably avoid setting max dimension altogether if one could use num_xps, num_dns etc. Just for future thoughts... > #define CMN_MAX_XPS (CMN_MAX_DIMENSION * CMN_MAX_DIMENSION) > #define CMN_MAX_DTMS (CMN_MAX_XPS + (CMN_MAX_DIMENSION - 1) * 4) > @@ -1692,8 +1802,13 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset) > cmn->num_dns += FIELD_GET(CMN_CI_CHILD_COUNT, reg); How about checking if child count is bigger than the maximum mesh size before this for loop? It would help in case someone would work on enabling support for new, bigger models and would forget to update CMN_MAX_DIMENSION... > } > > - /* Cheeky +1 to help terminate pointer-based iteration later */ > - dn = devm_kcalloc(cmn->dev, cmn->num_dns + 1, sizeof(*dn), GFP_KERNEL); > + /* > + * Some nodes effectively have two separate types, which we'll handle > + * by creating one of each internally. For a (very) safe initial upper > + * bound, account for double the number of non-XP nodes. > + */ > + dn = devm_kcalloc(cmn->dev, cmn->num_dns * 2 - cmn->num_xps, > + sizeof(*dn), GFP_KERNEL); > if (!dn) > return -ENOMEM; > > @@ -1970,6 +2098,7 @@ static int arm_cmn_remove(struct platform_device *pdev) > #ifdef CONFIG_OF > static const struct of_device_id arm_cmn_of_match[] = { > { .compatible = "arm,cmn-600", .data = (void *)CMN600 }, > + { .compatible = "arm,cmn-650", .data = (void *)CMN650 }, > { .compatible = "arm,ci-700", .data = (void *)CI700 }, > {} > }; > @@ -1979,6 +2108,7 @@ MODULE_DEVICE_TABLE(of, arm_cmn_of_match); > #ifdef CONFIG_ACPI > static const struct acpi_device_id arm_cmn_acpi_match[] = { > { "ARMHC600", CMN600 }, > + { "ARMHC650", CMN650 }, Not the great place for this comment but there probably isn't any better. Based on DEN0093 v1.1, CMN's DSDT entries have been changed since CMN-600. ROOTNODEBASE seems to be specific for CMN-600. Moreover, if you compare the address maps in TRMs' Discovery chapters, you can see the difference. I'm thinking, at the minimal the second platform_get_resource() call has to be skipped and zero returned in arm_cmn600_acpi_probe(), if the model is cmn650 (probably also for cmn-700) > {} > }; > MODULE_DEVICE_TABLE(acpi, arm_cmn_acpi_match); Cheers, Ilkka _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel