Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/xe/dp: Enable DP tunneling
Date: Tue, 21 Jan 2025 17:28:36 +0200	[thread overview]
Message-ID: <Z4-9JIZQjC1cGJsK@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <v5e2tnq6b7fr6rmi2mg24bf2x7jbljguce47s63ucugpvbiupa@z6r5kfxz6wth>

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

  reply	other threads:[~2025-01-21 15:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-13 15:48 [PATCH] drm/xe/dp: Enable DP tunneling Imre Deak
2025-01-13 16:20 ` ✓ CI.Patch_applied: success for " Patchwork
2025-01-13 16:20 ` ✓ CI.checkpatch: " Patchwork
2025-01-13 16:21 ` ✓ CI.KUnit: " Patchwork
2025-01-13 16:38 ` [PATCH] " Jani Nikula
2025-01-13 17:40   ` Imre Deak
2025-01-16 20:38     ` Lucas De Marchi
2025-01-17 15:55       ` Imre Deak
2025-01-17 16:45         ` Lucas De Marchi
2025-01-21 15:28           ` Imre Deak [this message]
2025-01-13 16:39 ` ✓ CI.Build: success for " Patchwork
2025-01-13 16:41 ` ✓ CI.Hooks: " Patchwork
2025-01-13 16:43 ` ✓ CI.checksparse: " Patchwork
2025-01-14 12:28 ` [PATCH v2] " Imre Deak
2025-01-16  5:17   ` Kandpal, Suraj
2025-01-14 12:33 ` ✗ Xe.CI.Full: failure for " Patchwork
2025-01-14 13:23 ` ✓ CI.Patch_applied: success for drm/xe/dp: Enable DP tunneling (rev2) Patchwork
2025-01-14 13:24 ` ✓ CI.checkpatch: " Patchwork
2025-01-14 13:25 ` ✓ CI.KUnit: " Patchwork
2025-01-14 13:43 ` ✓ CI.Build: " Patchwork
2025-01-14 13:45 ` ✓ CI.Hooks: " Patchwork
2025-01-14 13:47 ` ✓ CI.checksparse: " Patchwork
2025-01-14 14:13 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-14 17:54 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-16 19:07   ` Imre Deak
2025-01-16 20:32 ` [PATCH] drm/xe/dp: Enable DP tunneling Lucas De Marchi
2025-01-17 13:43   ` Imre Deak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z4-9JIZQjC1cGJsK@ideak-desk.fi.intel.com \
    --to=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=rodrigo.vivi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox