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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id D14A9C636D4 for ; Mon, 13 Feb 2023 18:17:00 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DEEB710E676; Mon, 13 Feb 2023 18:16:59 +0000 (UTC) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0611D10E676 for ; Mon, 13 Feb 2023 18:16:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676312218; x=1707848218; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=J4niuSN8gIklKAAL55qUfOPn4HVxFfv9JXS4kugTmWw=; b=PZGkXoVj2iAt9sPzdWLoSbf13MEupdL/jy+4cEssO6C0XlOeipUsZqae RC3EQWBcjDE3S/aYi0rdI1xKgJSpbChhZ3bDd7sngGPIm5slIFBixSHmf BUL6j4mi7vtZUjE3l7U3yKeGmELWFmk5O/AnTO5n3WySjR6xcViDFYNFH lTjvufq2aTh/AFrcXLsPocTsALZaSgXWCUnTLxfRhP2rT1TRLMCIRlhgC KDqnpJFTM4vy5V3nDMuZVyC8uOJVMVbu9jWcMTpAAUNvTUztZtk8sEATe D6H7UVYlZcZwtUboR53EWp33qpsRX1V5pYW5NjLatadTl/L8BGNjI0D+3 w==; X-IronPort-AV: E=McAfee;i="6500,9779,10620"; a="314598942" X-IronPort-AV: E=Sophos;i="5.97,294,1669104000"; d="scan'208";a="314598942" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2023 10:16:55 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10620"; a="842859181" X-IronPort-AV: E=Sophos;i="5.97,294,1669104000"; d="scan'208";a="842859181" Received: from joe-255.igk.intel.com (HELO localhost) ([10.91.220.57]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2023 10:16:53 -0800 Date: Mon, 13 Feb 2023 19:16:51 +0100 From: Stanislaw Gruszka To: =?iso-8859-1?Q?Ma=EDra?= Canal Subject: Re: Try to address the drm_debugfs issues Message-ID: <20230213181651.GA2822143@linux.intel.com> References: <20230209081838.45273-1-christian.koenig@amd.com> <0d9c852b-8639-55f4-4ec1-ca24f72d72f7@igalia.com> <4161ae4e-549c-00f6-5f37-f635a9cb775d@gmail.com> <613b9aec-7105-ca2d-13cd-16ddd85a6fda@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <613b9aec-7105-ca2d-13cd-16ddd85a6fda@igalia.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Christian =?iso-8859-1?Q?K=F6nig?= , dri-devel@lists.freedesktop.org, mwen@igalia.com, mairacanal@riseup.net, maxime@cerno.tech, daniel.vetter@ffwll.ch, wambui.karugax@gmail.com Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Feb 09, 2023 at 10:06:25AM -0300, Maíra Canal wrote: > > > [    3.872026] debugfs: File 'v3d_ident' in directory '0' already present! > > > [    3.872064] debugfs: File 'v3d_ident' in directory '128' already present! > > > [    3.872078] debugfs: File 'v3d_regs' in directory '0' already present! > > > [    3.872087] debugfs: File 'v3d_regs' in directory '128' already present! > > > [    3.872097] debugfs: File 'measure_clock' in directory '0' already present! > > > [    3.872105] debugfs: File 'measure_clock' in directory '128' already present! > > > [    3.872116] debugfs: File 'bo_stats' in directory '0' already present! > > > [    3.872124] debugfs: File 'bo_stats' in directory '128' already present! > > > > > > It looks like the render node is being added twice, since this doesn't happen > > > for vc4 and vkms. > > > > Thanks for the feedback and yes that's exactly what I meant with that I haven't looked into all code paths. > > > > Could it be that v3d registers it's debugfs files from the debugfs_init callback? > > Although this is true, I'm not sure if this is the reason why the files are > being registered twice, as this doesn't happen to vc4, and it also uses the > debugfs_init callback. I believe it is somewhat related to the fact that > v3d is the primary node and the render node. Yes, this seems to be because ->debugfs_init = v3d_debugfs_init() uses drm_debugfs_add_files() which create files for both primary and render. And ->debugfs_init is called via drm_minor_register() also for both when registering. Probably need to change debugfs_init callback to create files just for one minor. And if we don't want to use minor pointer directly in drivers, the callback can take debugfs dir as argument. Regards Stanislaw