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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E340EC0015E for ; Tue, 15 Aug 2023 13:25:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236796AbjHONYn (ORCPT ); Tue, 15 Aug 2023 09:24:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237440AbjHONYV (ORCPT ); Tue, 15 Aug 2023 09:24:21 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E65FD10C for ; Tue, 15 Aug 2023 06:24:19 -0700 (PDT) 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 F058F143D; Tue, 15 Aug 2023 06:25:01 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.3.119]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5DCF43F6C4; Tue, 15 Aug 2023 06:24:18 -0700 (PDT) Date: Tue, 15 Aug 2023 14:24:15 +0100 From: Mark Rutland To: Gowthami Thiagarajan Cc: "will@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Sunil Kovvuri Goutham , Bharat Bhushan , George Cherian , Linu Cherian Subject: Re: [PATCH 3/6] perf/marvell : Odyssey LLC-TAD performance monitor support Message-ID: References: <20230630120351.1143773-1-gthiagarajan@marvell.com> <20230630120351.1143773-4-gthiagarajan@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 12, 2023 at 01:51:00PM +0000, Gowthami Thiagarajan wrote: > > -----Original Message----- > > From: Mark Rutland > > Sent: Friday, July 28, 2023 9:08 PM > > To: Gowthami Thiagarajan > > Cc: will@kernel.org; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Sunil Kovvuri > > Goutham ; Bharat Bhushan ; George Cherian > > ; Linu Cherian > > Subject: [EXT] Re: [PATCH 3/6] perf/marvell : Odyssey LLC-TAD performance monitor support > > > > External Email > > > > ---------------------------------------------------------------------- > > On Fri, Jun 30, 2023 at 05:33:48PM +0530, Gowthami Thiagarajan wrote: > > > +static int tad_pmu_event_counter_add(struct perf_event *event, int flags) > > > +{ > > > + if (!event->attr.disabled) > > > + return -EINVAL; > > > > Why? > Just checks the default disabled attribute. Why does it matter? What's the problem with opening an event which is *not* disabled? [...] > > > +static int tad_pmu_probe(struct platform_device *pdev) > > > +{ > > > + struct device *dev = &pdev->dev; > > > + struct tad_region *regions; > > > + struct tad_pmu *tad_pmu; > > > + struct resource *res; > > > + u32 tad_pmu_page_size; > > > + u32 tad_page_size; > > > + u32 tad_cnt; > > > + int i, ret; > > > + char *name; > > > + > > > + tad_pmu = devm_kzalloc(&pdev->dev, sizeof(*tad_pmu), GFP_KERNEL); > > > + if (!tad_pmu) > > > + return -ENOMEM; > > > + > > > + platform_set_drvdata(pdev, tad_pmu); > > > + > > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > > + if (!res) { > > > + dev_err(&pdev->dev, "Mem resource not found\n"); > > > + return -ENODEV; > > > + } > > > + > > > + ret = device_property_read_u32(dev, "marvell,tad-page-size", &tad_page_size); > > > + if (ret) { > > > + dev_err(&pdev->dev, "Can't find tad-page-size property\n"); > > > + return ret; > > > + } > > > + > > > + ret = device_property_read_u32(dev, "marvell,tad-pmu-page-size", > > > + &tad_pmu_page_size); > > > + if (ret) { > > > + dev_err(&pdev->dev, "Can't find tad-pmu-page-size property\n"); > > > + return ret; > > > + } > > > > Why do you think these properties are necessary? > > > > These should almost certainly be provided by IO resources, and shouldn't need a > > custom property. > > IO resources don't provide all the information in this case. Need to vary these values > at different boot times. So, kept these custom properties. I think the only rason the information is missing is that your DT binding isn't quite right. Later on you do: + for (i = 0; i < tad_cnt && res->start < res->end; i++) { + regions[i].base = devm_ioremap(&pdev->dev, + res->start, + tad_pmu_page_size); + if (IS_ERR(regions[i].base)) { + dev_err(&pdev->dev, "TAD%d ioremap fail\n", i); + return -ENOMEM; + } + res->start += tad_page_size; + } ... which means you're splitting one reg entry into multiple mappings, whereas you could have multiple reg entries, one per TAD page. Thanks, Mark.