From patchwork Mon Dec 19 10:42:26 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: swati.dhingra@intel.com X-Patchwork-Id: 9480031 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 547C0606DB for ; Mon, 19 Dec 2016 10:36:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3D8DC283F8 for ; Mon, 19 Dec 2016 10:36:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 324862841B; Mon, 19 Dec 2016 10:36:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B633A283F8 for ; Mon, 19 Dec 2016 10:36:43 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 84D406E5B0; Mon, 19 Dec 2016 10:36:41 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4443D6E5AB; Mon, 19 Dec 2016 10:36:10 +0000 (UTC) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP; 19 Dec 2016 02:36:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,373,1477983600"; d="scan'208";a="204458280" Received: from swati-desktop.iind.intel.com ([10.223.82.38]) by fmsmga004.fm.intel.com with ESMTP; 19 Dec 2016 02:36:07 -0800 From: swati.dhingra@intel.com To: intel-gfx@lists.freedesktop.org Date: Mon, 19 Dec 2016 16:12:26 +0530 Message-Id: <1482144146-31605-5-git-send-email-swati.dhingra@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1482144146-31605-1-git-send-email-swati.dhingra@intel.com> References: <1482144146-31605-1-git-send-email-swati.dhingra@intel.com> Cc: Daniel Vetter , Swati Dhingra , dri-devel@lists.freedesktop.org, Alex Deucher , Sourab Gupta Subject: [Intel-gfx] [RFC 4/4] drm/i915: Creating guc log file in drmfs instead of debugfs X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP From: Sourab Gupta In the current scenario, the relay API fit well only with debugfs, due to availability of parent dentry. Any other existing filesystem was not feasible for holding guc logs, due to incompatibility with relay. But this makes the guc_log file unavailable on the production kernels. GuC log file can therefore be one of candidates for movement to the drmfs filesystem, which can satisfy all the requirements needed by relay API, and can house any relayfs based output file. The patch moves the parent directory of guc 'log_dir' from debugfs_root to drmfs_root, while using the drmfs api's to create the requisite files. Signed-off-by: Sourab Gupta Signed-off-by: Swati Dhingra --- drivers/gpu/drm/i915/i915_guc_submission.c | 33 +++++++++++------------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 5841380..3f5978a 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -22,8 +22,8 @@ * */ #include -#include #include +#include #include "i915_drv.h" #include "intel_uc.h" @@ -812,7 +812,7 @@ static int subbuf_start_callback(struct rchan_buf *buf, } /* - * file_create() callback. Creates relay file in debugfs. + * file_create() callback. Creates relay file. */ static struct dentry *create_buf_file_callback(const char *filename, struct dentry *parent, @@ -838,17 +838,19 @@ static struct dentry *create_buf_file_callback(const char *filename, * dentry of the file associated with the channel buffer and that file's * name need not be same as the filename passed as an argument. */ - buf_file = debugfs_create_file("guc_log", mode, + + buf_file = drmfs_create_file("guc_log", mode, parent, buf, &relay_file_operations); + return buf_file; } /* - * file_remove() default callback. Removes relay file in debugfs. + * file_remove() default callback. Removes relay file. */ static int remove_buf_file_callback(struct dentry *dentry) { - debugfs_remove(dentry); + drmfs_remove(dentry); return 0; } @@ -898,22 +900,11 @@ static int guc_log_create_relay_file(struct intel_guc *guc) struct dentry *log_dir; int ret; - /* For now create the log file in /sys/kernel/debug/dri/0 dir */ - log_dir = dev_priv->drm.primary->debugfs_root; - - /* If /sys/kernel/debug/dri/0 location do not exist, then debugfs is - * not mounted and so can't create the relay file. - * The relay API seems to fit well with debugfs only, for availing relay - * there are 3 requirements which can be met for debugfs file only in a - * straightforward/clean manner :- - * i) Need the associated dentry pointer of the file, while opening the - * relay channel. - * ii) Should be able to use 'relay_file_operations' fops for the file. - * iii) Set the 'i_private' field of file's inode to the pointer of - * relay channel buffer. - */ + /* Create the log file in drmfs dir: /sys/kernel/drm/i915/ */ + log_dir = dev_priv->drm.driver->drmfs_root; + if (!log_dir) { - DRM_ERROR("Debugfs dir not available yet for GuC log file\n"); + DRM_ERROR("Root dir not available yet for GuC log file\n"); return -ENODEV; } @@ -1154,7 +1145,7 @@ static int guc_log_create_extras(struct intel_guc *guc) if (!guc->log.relay_chan) { /* Create a relay channel, so that we have buffers for storing * the GuC firmware logs, the channel will be linked with a file - * later on when debugfs is registered. + * later on when drmfs is registered. */ ret = guc_log_create_relay_channel(guc); if (ret)