Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp4449052rwb; Mon, 8 Aug 2022 00:38:55 -0700 (PDT) X-Google-Smtp-Source: AA6agR7+S23dCudMgXjHsHR+ZCqEtWn2evtBUxol7CoF1e8sv6tv/LO09KUH4Dvx9LMHXO92zbaZ X-Received: by 2002:a05:6a00:a06:b0:52d:f9fa:8fc9 with SMTP id p6-20020a056a000a0600b0052df9fa8fc9mr17813949pfh.15.1659944335679; Mon, 08 Aug 2022 00:38:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659944335; cv=none; d=google.com; s=arc-20160816; b=ZPSsIsOM3/SwJPRak5X6WNa+daE5ZPrxp2CPYpt+POo5a6VW+Cv6xhCTb71QuCZhTY cXDGc+vHQuwWMUu2953KP3k7f/IDs8/dTC9f8x6MJ21gXnDqBzZyHQ+lepornu68ysww XDhXvV/MF5cseEQcSQzZ+y1N0JteKY3aO95boS5s3DBKaPF9yO+G0wL7SwUYLthd/Kkw 5bTCzqVVsx7dXlHK/P/HEMWiatM9fN9N/Iqnl3GnVXz1ERavpdmaW9Bv/4lIJ83D1V46 hljAOxx7LrFYn2tlmYO/irVxlsE52IAoFF8K0wVwSbc4+MWbsaKUoZAzgFaxUC6M9eU9 K63Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=7+fe69BslonBp33hoPWSuIIEXP5odJQdkKug3X8K6tk=; b=VJGnXkOkL6OYdJVrfCrfLlpr+fZGuOwywEQxAZpMSeFuDuaJji2uEdT6k619krdCtB ILSdrB4fvcWPgeJXJxjtjDGYcn2zbAcxsKW29jnkfnX0KiOGICNAa4X7N+sSmE9Qia1Y QgHojXUu14pUYtSBXEn2rSh8dbye3Mk1S9P+gEJ5r9925+NW1Vd5o359Y/YF57dBL7aS BQ/MClJqWi0OlfVex11bfv1YMaZNLbefeYBweG7MlRGfGYmL1DyzSN0xHyfTsbgtcjTD uZZF4aCPRh8m2OVYcjVJwkZl2bRswLms7aDhnZoPWNlvZWYWg8v1uBCQfuq9dATIV/lA Cwkw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c13-20020a170902d48d00b0016be6146f7fsi6114225plg.192.2022.08.08.00.38.41; Mon, 08 Aug 2022 00:38:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241831AbiHHHhN (ORCPT + 99 others); Mon, 8 Aug 2022 03:37:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239287AbiHHHgu (ORCPT ); Mon, 8 Aug 2022 03:36:50 -0400 Received: from mail-sz.amlogic.com (mail-sz.amlogic.com [211.162.65.117]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FFE1120BC; Mon, 8 Aug 2022 00:36:44 -0700 (PDT) Received: from [10.88.19.200] (10.88.19.200) by mail-sz.amlogic.com (10.28.11.5) with Microsoft SMTP Server id 15.1.2507.6; Mon, 8 Aug 2022 15:36:39 +0800 Message-ID: <0431a041-17b8-39d5-ed03-3036d556ec05@amlogic.com> Date: Mon, 8 Aug 2022 15:36:39 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0.2 Subject: Re: [PATCH v4 1/4] perf/amlogic: Add support for Amlogic meson G12 SoC DDR PMU driver Content-Language: en-US To: Krzysztof Kozlowski , , , , CC: Rob Herring , Krzysztof Kozlowski , Will Deacon , Mark Rutland , Neil Armstrong , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , Chris Healy , kernel test robot References: <20220805071426.2598818-1-jiucheng.xu@amlogic.com> <3597d068-2c44-9450-4a0c-4704f3639a37@linaro.org> <4119d339-0570-2132-3e9f-19ec45ef6e8d@amlogic.com> From: Jiucheng Xu In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.88.19.200] X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/8/8 13:42, Krzysztof Kozlowski wrote: > [ EXTERNAL EMAIL ] > > On 05/08/2022 11:55, Jiucheng Xu wrote: >>>> +static int __init g12_ddr_pmu_probe(struct platform_device *pdev) >>>> +{ >>>> + struct ddr_pmu *pmu; >>>> + >>>> + if (of_device_is_compatible(pdev->dev.of_node, >>>> + "amlogic,g12a-ddr-pmu")) { >>>> + format_attr_nna.attr.mode = 0; >>>> + format_attr_gdc.attr.mode = 0; >>>> + format_attr_arm1.attr.mode = 0; >>>> + format_attr_mipi_isp.attr.mode = 0; >>> No. That's not correct patter. You must use variant specific driver data. >> Do you mean use of_device_id.data? Could your please give me an >> >> example code in kernel source? > 90% of Linux kernel drivers? > >>>> + }, >>>> + { >>>> + .compatible = "amlogic,g12a-ddr-pmu", >>>> + }, >>>> + { >>>> + .compatible = "amlogic,g12b-ddr-pmu", >>>> + }, >>>> + { >>>> + .compatible = "amlogic,sm1-ddr-pmu", >>> Why four different entries for the same devices without driver data? >>> This is confusing. >> Do you mean use a common compatible and different driver data? > What I meant is that current version this is useless and confusing. > Different devices have different compatibles with different driver data. > Same devices have just the same compatible (so same driver data). You > mixed two different approaches. Does the driver data must be necessary? Although G12A, G12B and SM1 are different devices, but they have the same control interface. The only difference is that G12B has 4 extra modules be supported than G12A. > >>>> + }, >>>> + {} >>>> +}; >>>> + >>>> +static struct platform_driver g12_ddr_pmu_driver = { >>>> + .driver = { >>>> + .name = "amlogic,ddr-pmu", >>>> + .of_match_table = meson_ddr_pmu_dt_match, >>>> + }, >>>> + .remove = __exit_p(g12_ddr_pmu_remove), >>> You made the driver non-hotpluggable - why? >>> In the same time it is still unbindable, whis is a bit confusing. If you >>> can unbind it, you should be able to hot-unplug it. >> Sorry, I couldn't know why the driver is non-hotpluggable. Could you >> tell the detail? > You used module_platform_driver_probe, so the one with documentation: > /* non-hotpluggable platform devices may use this so that probe() and > > * its support may live in __init sections, conserving runtime memory. > > */ Okay, module_platform_driver_probeļ¼ˆ) was suggested by Robin Murphy , but you gave the reason. module_platform_driver() is okay? > > >>>> +}; >>>> + >>>> +module_platform_driver_probe(g12_ddr_pmu_driver, g12_ddr_pmu_probe); >>>> +MODULE_AUTHOR("Jiucheng Xu"); >>>> +MODULE_LICENSE("GPL"); >>>> +MODULE_DESCRIPTION("Amlogic G12 series SoC DDR PMU"); >>>> diff --git a/include/soc/amlogic/meson_ddr_pmu.h b/include/soc/amlogic/meson_ddr_pmu.h >>>> new file mode 100644 >>>> index 000000000000..882efe3c2f58 >>>> --- /dev/null >>>> +++ b/include/soc/amlogic/meson_ddr_pmu.h >>>> @@ -0,0 +1,76 @@ >>>> +/* SPDX-License-Identifier: GPL-2.0 */ >>>> +/* >>>> + * Copyright (c) 2022 Amlogic, Inc. All rights reserved. >>>> + */ >>>> + >>>> +#ifndef __MESON_DDR_PMU_H__ >>>> +#define __MESON_DDR_PMU_H__ >>>> + >>>> +#define MAX_CHANNEL_NUM 8 >>>> + >>>> +enum { >>>> + ALL_CHAN_COUNTER_ID, >>>> + CHAN1_COUNTER_ID, >>>> + CHAN2_COUNTER_ID, >>>> + CHAN3_COUNTER_ID, >>>> + CHAN4_COUNTER_ID, >>>> + CHAN5_COUNTER_ID, >>>> + CHAN6_COUNTER_ID, >>>> + CHAN7_COUNTER_ID, >>>> + CHAN8_COUNTER_ID, >>>> + COUNTER_MAX_ID, >>>> +}; >>>> + >>>> +struct dmc_hw_info; >>>> + >>>> +struct dmc_counter { >>>> + u64 all_cnt; /* The count of all requests come in/out ddr controller */ >>>> + union { >>>> + u64 all_req; >>>> + struct { >>>> + u64 all_idle_cnt; >>>> + u64 all_16bit_cnt; >>>> + }; >>>> + }; >>>> + u64 channel_cnt[MAX_CHANNEL_NUM]; /* To save a DMC bandwidth-monitor channel counter */ >>>> +}; >>>> + >>>> +struct dmc_pmu_hw_ops { >>>> + void (*enable)(struct dmc_hw_info *info); >>>> + void (*disable)(struct dmc_hw_info *info); >>>> + /* Bind an axi line to a bandwidth-monitor channel */ >>>> + void (*config_axi_id)(struct dmc_hw_info *info, int axi_id, int chann); >>>> + int (*irq_handler)(struct dmc_hw_info *info, >>>> + struct dmc_counter *counter); >>>> + void (*get_counters)(struct dmc_hw_info *info, >>>> + struct dmc_counter *counter); >>>> +}; >>>> + >>>> +struct dmc_hw_info { >>>> + struct dmc_pmu_hw_ops *ops; >>>> + void __iomem *ddr_reg[4]; >>>> + unsigned long timer_value; /* Timer value in TIMER register */ >>>> + void __iomem *pll_reg; >>>> + int irq_num; /* irq vector number */ >>>> + int dmc_nr; /* The number of dmc controller */ >>>> + int chann_nr; /* The number of dmc bandwidth monitor channels */ >>>> + int id; /* The number of supported channels */ >>>> + struct attribute **fmt_attr; >>>> +}; >>>> + >>>> +struct ddr_pmu { >>>> + struct pmu pmu; >>>> + struct dmc_hw_info info; >>>> + struct dmc_counter counters; /* save counters from hw */ >>>> + bool pmu_enabled; >>>> + struct device *dev; >>>> + char *name; >>>> + struct hlist_node node; >>>> + enum cpuhp_state cpuhp_state; >>>> + int cpu; /* for cpu hotplug */ >>>> +}; >>> Linux-wide headers should not include your private data structures. >>> Entier header looks unused - should be made private. >> Do you mean the header should be in driver dir, or the structures should >> be within .c file? > This or that, up to you. Definitely not in include/linux/. I see other PMU drivers' header are in include/soc/xxx/. I just follow them. meson G12 series SoC DDR PMU driver is the first PMU driver got upstream, and other series will be got upstream in the future. So I think the structures are public. Does this make sense? > > > Best regards, > Krzysztof > -- Thanks, Jiucheng