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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 1D559C3E8AF for ; Fri, 13 Dec 2019 20:49:58 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1B9752469E for ; Fri, 13 Dec 2019 20:49:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1B9752469E Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=etezian.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 536A36E8C7; Fri, 13 Dec 2019 14:52:06 +0000 (UTC) Received: from 2.mo179.mail-out.ovh.net (2.mo179.mail-out.ovh.net [178.33.250.45]) by gabe.freedesktop.org (Postfix) with ESMTPS id A970A6E8C7 for ; Fri, 13 Dec 2019 14:52:05 +0000 (UTC) Received: from player799.ha.ovh.net (unknown [10.109.146.19]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id A48E5152C4B for ; Fri, 13 Dec 2019 15:44:08 +0100 (CET) Received: from etezian.org (net-37-116-49-191.cust.vodafonedsl.it [37.116.49.191]) (Authenticated sender: andi@etezian.org) by player799.ha.ovh.net (Postfix) with ESMTPSA id BD18BD373478; Fri, 13 Dec 2019 14:44:04 +0000 (UTC) Date: Fri, 13 Dec 2019 16:44:04 +0200 From: Andi Shyti To: Chris Wilson Message-ID: <20191213144404.GB5108@jack.zhora.eu> References: <20191213124549.28412-1-andi@etezian.org> <20191213124549.28412-3-andi@etezian.org> <157624155700.6987.7147279410865367970@skylake-alporthouse-com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <157624155700.6987.7147279410865367970@skylake-alporthouse-com> User-Agent: Mutt/1.12.2 (2019-09-21) X-Ovh-Tracer-Id: 11797179225997689353 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrudelledgieekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheptehnughiucfuhhihthhiuceorghnughisegvthgviihirghnrdhorhhgqeenucfkpheptddrtddrtddrtddpfeejrdduudeirdegledrudeludenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeelledrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpegrnhguihesvghtvgiiihgrnhdrohhrghdprhgtphhtthhopehinhhtvghlqdhgfhigsehlihhsthhsrdhfrhgvvgguvghskhhtohhprdhorhhgnecuvehluhhsthgvrhfuihiivgeptd Subject: Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gt: Move power management debug files into a gt aware debugfs X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Intel GFX Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Hi Chris, > > +int intel_gt_pm_debugfs_register(struct intel_gt *gt) > > +{ > > + struct dentry *root = gt->debugfs_entry; > > + int i; > > + > > + pr_info("ANDIII function start\n"); > > + if (unlikely(!root)) > > + return -ENODEV; > > + > > + for (i = 0; i < ARRAY_SIZE(gt_pm_debugfs_files); i++) { > > + const struct gt_pm_debugfs_files *f = >_pm_debugfs_files[i]; > > + > > + if (f->eval && !f->eval(gt)) > > + continue; > > + > > + debugfs_create_file(f->name, 0444, root, gt, f->fops); > > + } > > + pr_info("ANDIII function end\n"); > > + > > + return 0; > > Looking better! you liked my wonderful debugging printouts? :D > Do we even need to keep the gt->debugfs_entry around? Yes, that can be removed, indeed, I was thinking that perhaps in the future we might need that pointer, but yes, definitely not necessary. > We are not going to ever do hotplug are we and so only > need to populate once? for example? do you mean something like files generated in certain conditions, like during interrupts or files generated and destroyed depending on the power state? If so, you might want an interface for generating/destroying files, but do we have such case now to really care about? Andi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx