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 48F70C43334 for ; Wed, 20 Jul 2022 03:40:40 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9FC2289590; Wed, 20 Jul 2022 03:40:33 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8029F10FC71 for ; Wed, 20 Jul 2022 03:40:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658288431; x=1689824431; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=KlRkIKaggCGWvlwjiQWTK3oWYrcyGJhV+k1H/zohs2g=; b=XDTSgVmgBgcbJniMGp4FNBQ7pe9ZxLOElWxwRNFccMoxi5Vwp5LqoufK J25APTm8bVBf/7ccumt2zZ5/YEMOHlmvuGmDitpKNgTXO91CrA/C/RP2T IIns2mYAlfkq+Q7Z1lSWE5Ljr9EiZJ7EM09jdgauajcm2WJc0IVPe691w Rc+gCyGaxGTCggYE/HergsCBN6rHeMK/bng5An/Md13no29fflN9q47wP k9BszmaA4udSb81IFJG0+D9Psy6mxUeGvJv55k2mpw3e+B6HX1wcPOcIb I1CCbnmQSGpQj59DtNsOGyBjBTwRPJ6cPoxlpCWEIIetxptB11786PAbl A==; X-IronPort-AV: E=McAfee;i="6400,9594,10413"; a="284230981" X-IronPort-AV: E=Sophos;i="5.92,285,1650956400"; d="scan'208";a="284230981" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2022 20:40:28 -0700 X-IronPort-AV: E=Sophos;i="5.92,285,1650956400"; d="scan'208";a="700712880" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.70.164]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2022 20:40:28 -0700 Date: Tue, 19 Jul 2022 20:40:27 -0700 Message-ID: <87lesobges.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Alan Previn In-Reply-To: <20220509210151.1843173-5-alan.previn.teres.alexis@intel.com> References: <20220509210151.1843173-1-alan.previn.teres.alexis@intel.com> <20220509210151.1843173-5-alan.previn.teres.alexis@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-gfx] [Intel-gfx 4/6] drm/i915/guc: Provide debugfs for log relay sub-buf info 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@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, 09 May 2022 14:01:49 -0700, Alan Previn wrote: > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c > index f454d53a8bca..35709202b09c 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c > @@ -15,7 +15,7 @@ > > static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log); > > -static u32 intel_guc_log_size(struct intel_guc_log *log) > +u32 intel_guc_log_size(struct intel_guc_log *log) > { > /* > * GuC Log buffer Layout: > @@ -41,6 +41,12 @@ static u32 intel_guc_log_size(struct intel_guc_log *log) > return PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE + CAPTURE_BUFFER_SIZE; > } > > +#define GUC_LOG_RELAY_SUBBUF_COUNT 8 > +u32 intel_guc_log_relay_subbuf_count(struct intel_guc_log *log) > +{ > + return GUC_LOG_RELAY_SUBBUF_COUNT; > +} uapi wise, instead of exposing guc_log_size and subbuf_count, why not expose subbuf_size and subbuf_count? > +static int guc_log_relay_buf_size_get(void *data, u64 *val) > +{ > + struct intel_guc_log *log = data; > + > + if (!log) > + return -ENODEV; > + if (!log->vma) > + return -ENODEV; Why are these checks needed? Hasn't log been initialized and attached at intel_gt_debugfs_register_files()/debugfs_create_file() time itself? Also if needed let's do: if (!log || !log->vma) return -ENODEV; > + > + *val = (u64)intel_guc_log_size(log); > + > + return 0; > +} > + > +DEFINE_SIMPLE_ATTRIBUTE(guc_log_relay_buf_size_fops, > + guc_log_relay_buf_size_get, NULL, > + "%lld\n"); > + > +static int guc_log_relay_subbuf_count_get(void *data, u64 *val) > +{ > + struct intel_guc_log *log = data; > + > + if (!log) > + return -ENODEV; > + if (!log->vma) > + return -ENODEV; Same issue as above. > + > + *val = intel_guc_log_relay_subbuf_count(log); > + > + return 0; > +} > + > +DEFINE_SIMPLE_ATTRIBUTE(guc_log_relay_subbuf_count_fops, > + guc_log_relay_subbuf_count_get, NULL, > + "%lld\n"); > + > static int guc_log_relay_open(struct inode *inode, struct file *file) > { > struct intel_guc_log *log = inode->i_private; > > + if (!log) > + return -ENODEV; > + Same issue as above. > if (!intel_guc_is_ready(log_to_guc(log))) > return -ENODEV; > > @@ -166,6 +205,8 @@ void intel_guc_log_debugfs_register(struct intel_guc_log *log, > { "guc_load_err_log_dump", &guc_load_err_log_dump_fops, NULL }, > { "guc_log_level", &guc_log_level_fops, NULL }, > { "guc_log_relay", &guc_log_relay_fops, NULL }, > + { "guc_log_relay_buf_size", &guc_log_relay_buf_size_fops, NULL }, > + { "guc_log_relay_subbuf_count", &guc_log_relay_subbuf_count_fops, NULL }, > }; > > if (!intel_guc_is_supported(log_to_guc(log))) > -- > 2.25.1 >