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 E2D57ECE57A for ; Mon, 9 Sep 2024 13:40:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8A6A010E580; Mon, 9 Sep 2024 13:40:53 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="aebdv42g"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by gabe.freedesktop.org (Postfix) with ESMTPS id 03E1810E580 for ; Mon, 9 Sep 2024 13:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725889253; x=1757425253; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=drw1Rz18BhYgCxMsclszpItb36ny8Hb8wjcBfb2nYIo=; b=aebdv42geq+43w22rpMhckaLXtGnLWh4Q6Lhcf3fDvRm6z3L4elWlz+Q Uo5wdUGtFjCTRQKOz4QrtmyUiQB1UGN7QCzkffbhLjZrlNLCbMVjMtDzL 5u7cfmYc7kFDPhIsnkUeCw74t5p79aLRC5xg9pHA8XzPgjSazNdbttK5d lF3oJXScdNxw+M0+F8I7ig7YxjSSVGMZVoJnBxDGHBPrwIfPGUVVaN03p Sv2KxsCLvr11Ct4IZzS2slcbd+y+HZereFTc5eZohbye4vgkiDiWsz1eZ AGg95T/8L475IgnyggzRlIc94dwUQlTIYc1TpgsLXMnNkWkcp3Z+vMvS4 Q==; X-CSE-ConnectionGUID: lOoJX6olQeOt4qeuHtX5/w== X-CSE-MsgGUID: iKdgmaskTsmDny+n1zz4Ww== X-IronPort-AV: E=McAfee;i="6700,10204,11190"; a="24451449" X-IronPort-AV: E=Sophos;i="6.10,214,1719903600"; d="scan'208";a="24451449" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2024 06:40:36 -0700 X-CSE-ConnectionGUID: dRC+6hL9QMah4U86lE64ug== X-CSE-MsgGUID: wjqSjiH2TbWAIer+AFji5w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,214,1719903600"; d="scan'208";a="66733720" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.74]) by fmviesa008.fm.intel.com with SMTP; 09 Sep 2024 06:40:34 -0700 Received: by stinkbox (sSMTP sendmail emulation); Mon, 09 Sep 2024 16:40:33 +0300 Date: Mon, 9 Sep 2024 16:40:33 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: "Nautiyal, Ankit K" Cc: intel-gfx@lists.freedesktop.org, jani.saarinen@intel.com Subject: Re: [PATCH 01/14] drm/i915/display: Modify debugfs for joiner to force n pipes Message-ID: References: <20240906125807.3960642-1-ankit.k.nautiyal@intel.com> <20240906125807.3960642-2-ankit.k.nautiyal@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment 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: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, Sep 09, 2024 at 11:10:16AM +0530, Nautiyal, Ankit K wrote: > > On 9/6/2024 8:24 PM, Ville Syrjälä wrote: > > On Fri, Sep 06, 2024 at 05:46:11PM +0300, Ville Syrjälä wrote: > >> On Fri, Sep 06, 2024 at 06:27:54PM +0530, Ankit Nautiyal wrote: > >>> At the moment, the debugfs for joiner allows only to force enable/disable > >>> pipe joiner for 2 pipes. Modify it to force join 'n' number of pipes, > >>> where n is a valid pipe joiner configuration. > >>> This will help in case of ultra joiner where 4 pipes are joined. > >>> > >>> v2: > >>> -Fix commit message to state that only valid joiner config can be > >>> forced. (Suraj) > >>> -Rename the identifiers to have INTEL_BIG/NONE_JOINER_PIPES. (Suraj) > >>> > >>> Signed-off-by: Ankit Nautiyal > >>> --- > >>> .../drm/i915/display/intel_display_debugfs.c | 71 ++++++++++++++++++- > >>> .../drm/i915/display/intel_display_types.h | 8 ++- > >>> drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > >>> 3 files changed, 77 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > >>> index 830b9eb60976..0ef573afd8a1 100644 > >>> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > >>> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > >>> @@ -1504,6 +1504,73 @@ static int intel_crtc_pipe_show(struct seq_file *m, void *unused) > >>> } > >>> DEFINE_SHOW_ATTRIBUTE(intel_crtc_pipe); > >>> > >>> +static int i915_joiner_show(struct seq_file *m, void *data) > >>> +{ > >>> + struct intel_connector *connector = m->private; > >>> + struct drm_i915_private *i915 = to_i915(connector->base.dev); > >>> + int ret; > >>> + > >>> + ret = drm_modeset_lock_single_interruptible(&i915->drm.mode_config.connection_mutex); > >>> + if (ret) > >>> + return ret; > >> What does that lock do for us? > >> > >>> + > >>> + seq_printf(m, "Force_joined_pipes: %d\n", connector->force_joined_pipes); > >> This should just be thae bare number. Adding other junk in there just > >> complicates matters if anyone has to parse this. > >> > >>> + > >>> + drm_modeset_unlock(&i915->drm.mode_config.connection_mutex); > >>> + > >>> + return ret; > >>> +} > >>> + > >>> +static ssize_t i915_joiner_write(struct file *file, > >>> + const char __user *ubuf, > >>> + size_t len, loff_t *offp) > >>> +{ > >>> + struct seq_file *m = file->private_data; > >>> + struct intel_connector *connector = m->private; > >>> + struct drm_i915_private *i915 = to_i915(connector->base.dev); > >>> + int force_join_pipes = 0; > >>> + int ret; > >>> + > >>> + if (len == 0) > >>> + return 0; > >>> + > >>> + drm_dbg(&i915->drm, > >>> + "Copied %zu bytes from user to force joiner\n", len); > >> Leftover debug junk. > >> > >>> + > >>> + ret = kstrtoint_from_user(ubuf, len, 0, &force_join_pipes); > >>> + if (ret < 0) > >>> + return ret; > >>> + > >>> + drm_dbg(&i915->drm, "Got %d for force joining pipes\n", force_join_pipes); > >> More. > >> > >>> + > >>> + if (force_join_pipes < INTEL_NONE_JOINER_PIPES || > >>> + force_join_pipes >= INTEL_INVALID_JOINER_PIPES) { > >>> + drm_dbg(&i915->drm, "Ignoring Invalid num of pipes %d for force joining\n", > >>> + force_join_pipes); > >>> + connector->force_joined_pipes = INTEL_NONE_JOINER_PIPES; > >>> + } else { > >>> + connector->force_joined_pipes = force_join_pipes; > >>> + } > >> I think just something like > >> switch (num_pipes) { > >> case 0: /* or should 1 be the default? */ > > I suppose both 0 and 1 should be accepted. 0==not forced, 1==forced to > > exactly one pipe (ie. no joiner despite what the automagic logic > > is saying). > > I understand 0 as not forced. I didnt get the meaning of forcing to one > pipe. > > Does this mean, disable joiner? (Perhaps do not use joiner even for the > cases where driver thinks joiner is required) > > How should we handle the case in driver, where it is 1? Whatever code that determines how many pipes will should: 1) if the override is non-zero just use it 2) otherwise determine the number by using whatever logic is appropriate > > > Regards, > > Ankit > > > > >> case 2: > >> case 4: > >> break; > >> default: > >> bad; > >> } > >> > >> should do for validation. > >> -- Ville Syrjälä Intel