Messages in this thread | | | From | Gowthami Thiagarajan <> | Subject | RE: [EXT] Re: [PATCH 3/6] perf/marvell : Odyssey LLC-TAD performance monitor support | Date | Thu, 17 Aug 2023 13:26:14 +0000 |
| |
Hi Mark/Will,
> -----Original Message----- > From: Mark Rutland <mark.rutland@arm.com> > Sent: Tuesday, August 15, 2023 6:54 PM > To: Gowthami Thiagarajan <gthiagarajan@marvell.com> > Cc: will@kernel.org; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Sunil Kovvuri > Goutham <sgoutham@marvell.com>; Bharat Bhushan <bbhushan2@marvell.com>; George Cherian > <gcherian@marvell.com>; Linu Cherian <lcherian@marvell.com> > Subject: [EXT] Re: [PATCH 3/6] perf/marvell : Odyssey LLC-TAD performance monitor support > > External Email > > ---------------------------------------------------------------------- > On Sat, Aug 12, 2023 at 01:51:00PM +0000, Gowthami Thiagarajan wrote: > > > -----Original Message----- > > > From: Mark Rutland <mark.rutland@arm.com> > > > Sent: Friday, July 28, 2023 9:08 PM > > > To: Gowthami Thiagarajan <gthiagarajan@marvell.com> > > > Cc: will@kernel.org; linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Sunil > Kovvuri > > > Goutham <sgoutham@marvell.com>; Bharat Bhushan <bbhushan2@marvell.com>; George Cherian > > > <gcherian@marvell.com>; Linu Cherian <lcherian@marvell.com> > > > 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? > > [...] Checked this. Don't find the significance of the validation. Can be removed. > > > > > +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.
These properties are updated by the firmware at runtime. In order to avoid the firmware updating multiple nodes, a single node for the entire system has been kept. So that the firmware can just update at a single place .
Thanks, Gowthami
> > Thanks, > Mark.
| |