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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 F1980C10F00 for ; Sat, 7 Mar 2020 12:55:44 +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 8C47F2073C for ; Sat, 7 Mar 2020 12:55:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C47F2073C 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 EE51A89DE5; Sat, 7 Mar 2020 12:55:43 +0000 (UTC) Received: from 10.mo179.mail-out.ovh.net (10.mo179.mail-out.ovh.net [46.105.79.46]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7E20C89DE5 for ; Sat, 7 Mar 2020 12:55:41 +0000 (UTC) Received: from player770.ha.ovh.net (unknown [10.108.54.74]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 678CB15C9A0 for ; Sat, 7 Mar 2020 13:55:38 +0100 (CET) Received: from etezian.org (81-175-223-118.bb.dnainternet.fi [81.175.223.118]) (Authenticated sender: andi@etezian.org) by player770.ha.ovh.net (Postfix) with ESMTPSA id E0E30103EDE95; Sat, 7 Mar 2020 12:55:32 +0000 (UTC) Date: Sat, 7 Mar 2020 14:55:31 +0200 From: Andi Shyti To: Chris Wilson Message-ID: <20200307125531.GA58713@jack.zhora.eu> References: <20200306230344.53559-1-andi@etezian.org> <158358284291.6224.14954481538219251460@build.alporthouse.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <158358284291.6224.14954481538219251460@build.alporthouse.com> X-Ovh-Tracer-Id: 11081669834274095625 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedruddugedggeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhguihcuufhhhihtihcuoegrnhguihesvghtvgiiihgrnhdrohhrgheqnecukfhppedtrddtrddtrddtpdekuddrudejhedrvddvfedruddukeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejjedtrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomheprghnughisegvthgviihirghnrdhorhhgpdhrtghpthhtohepihhnthgvlhdqghhfgieslhhishhtshdrfhhrvggvuggvshhkthhophdrohhrgh Subject: Re: [Intel-gfx] [PATCH v4] drm/i915/gt: allow setting generic data pointer 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, On Sat, Mar 07, 2020 at 12:07:22PM +0000, Chris Wilson wrote: > Quoting Andi Shyti (2020-03-06 23:03:44) > > -void debugfs_gt_register_files(struct intel_gt *gt, > > - struct dentry *root, > > - const struct debugfs_gt_file *files, > > - unsigned long count) > > +void intel_gt_debugfs_register_files(struct dentry *root, > > + const struct debugfs_gt_file *files, > > + unsigned long count, void *data) > > { > > while (count--) { > > - if (!files->eval || files->eval(gt)) > > + if (!files->eval || files->eval(data)) > > debugfs_create_file(files->name, > > - 0444, root, gt, > > + 0444, root, data, > > files->fops); > > > > And now we are not a intel_gt routine, you'll want to move again :) > i915_debugfs_utils.c ? :) Actually, this is what it came to and this was the first discussion I had with Daniele and that's also why I was loyal to th "_gt_" wrappers until the end. But I had to agree that this was becoming more a limitation. The biggest difference left, which by the way is the real distinguishing factor other than the *gt pointer, is that we create files under gt directory, instead of having the root imposed by the drm (even though the caller can eventually choose different roots). We could perhaps store the root pointer in the intel_gt structure so that this function stays de facto an intel_gt routine and the caller doesn't need to care where the files will be generated. This is what we planned to do with sysfs as well. What do you think? Andi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx