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 via email to