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 D6D88C0218C for ; Tue, 21 Jan 2025 15:27:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9E45510E1FB; Tue, 21 Jan 2025 15:27:46 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="PxTcUnyB"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by gabe.freedesktop.org (Postfix) with ESMTPS id 918DC10E1FB; Tue, 21 Jan 2025 15:27:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737473264; x=1769009264; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=2ScYngx43+Vo+7fL7HuTQMTb9DxCGy5CtTn6l/84BYY=; b=PxTcUnyBBz8VB6cFfIcL+wXDO+sWZ/ntVXrZWhuDjLxTw+AN8dAZCi/m CBhRZFfsP/IcqU2Zt2ZyKXZdmsJOhbn8HvXqOeIKkvM8IJaNwzhqGpCw1 rJTTIpMOTUagnYq6hVA/TIZjuOSvaGWtX6W4VyFTbBtMpP+4SqlyuyZmg 3h15ka8y7d95n0r4ZqUWLtBOblwfi8R4t5NnRBRjFPyvB0ZUsLdzLgn9S XQXBhwvFtip1GtsHOF/wsmidl8B4oWm5GAtFbmBOM154SZiamqqpTpFqI LLh4h4g/649y/+a8bTDESlKCebvAUTC/LP6ix9S3PIrqBopYvadNdrvKR w==; X-CSE-ConnectionGUID: ajvOTdNST7ePhx20QYscGQ== X-CSE-MsgGUID: E1/0SUIMSrudjrpy4D9C4Q== X-IronPort-AV: E=McAfee;i="6700,10204,11314"; a="49307096" X-IronPort-AV: E=Sophos;i="6.12,310,1728975600"; d="scan'208";a="49307096" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2025 07:27:44 -0800 X-CSE-ConnectionGUID: 18t3f6oDQVSI7jUJ+yxv8A== X-CSE-MsgGUID: WyvojPSJQJmAQWgEsTMNQA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,222,1732608000"; d="scan'208";a="106628092" Received: from ideak-desk.fi.intel.com ([10.237.72.78]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jan 2025 07:27:42 -0800 Date: Tue, 21 Jan 2025 17:28:36 +0200 From: Imre Deak To: Lucas De Marchi Cc: Jani Nikula , intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, Rodrigo Vivi Subject: Re: [PATCH] drm/xe/dp: Enable DP tunneling Message-ID: References: <20250113154832.1004369-1-imre.deak@intel.com> <87cygqis8l.fsf@intel.com> <7br5fcyxwpapyyd646rqyja47wjxmgpnhvyramt64kumqevyua@codb2qklp2hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: imre.deak@intel.com Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Fri, Jan 17, 2025 at 10:45:56AM -0600, Lucas De Marchi wrote: > [...] > > > > > > diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig > > > > > > index b51a2bde73e29..50cf80df51900 100644 > > > > > > --- a/drivers/gpu/drm/xe/Kconfig > > > > > > +++ b/drivers/gpu/drm/xe/Kconfig > > > > > > @@ -59,6 +59,20 @@ config DRM_XE_DISPLAY > > > > > > help > > > > > > Disable this option only if you want to compile out display support. > > > > > > > > > > > > +config DRM_XE_DP_TUNNEL > > > > > > + bool "Enable DP tunnel support" > > > > > > + depends on DRM_XE > > > > > > + depends on USB4 > > > > > > + select DRM_DISPLAY_DP_TUNNEL > > > > > > + default y > > > > > > + help > > > > > > + Choose this option to detect DP tunnels and enable the Bandwidth > > > > > > + Allocation mode for such tunnels. This allows using the maximum > > > > > > + resolution allowed by the link BW on all displays sharing the > > > > > > + link BW, for instance on a Thunderbolt link. > > > > > > + > > > > > > + If in doubt say "Y". > > > > > > + > > > > > > > > > > I'm sort of wondering why we have this (and the i915 one) as > > > > > user-selectable config options at all. Is it ever reasonable for the > > > > > user to disable this if USB4 is enabled? > > > > > > > > On platforms that don't support DP tunneling, while supporting other > > > > USB4 functionality (or for systems w/o any TypeC/DP connectors) it would > > > > make sense to disable this option. > > > > > > isn't this too fine grained? if we expose every single functionality of > > > the driver like this we will bury distros on configs and exponentially > > > explode the testing combination. And yes, this broke the build for me. > > > > The tunneling functionality depends on USB4, BW allocation could fail > > without that. The option being user selectable also makes sense to me, > > as it has a size (~30kB) and runtime overhead (detecting tunnels and > > allocating/freeing BW), only required if the user has a dock/multiple > > displays. > > I will leave this up to the display maintainers - I still think it's too > fine grained to have this option as user selectable and worse, in 2 > drivers.... does the user have to know which driver officially support > that hardware to enable one and disable the other? All the display options should be configured at one place, but that's only feasible with a separate display module (which is the goal afaik). > Lucas De Marchi