From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: linux-usb@vger.kernel.org,
Yehezkel Bernat <YehezkelShB@gmail.com>,
Michael Jamet <michael.jamet@intel.com>,
Andreas Noever <andreas.noever@gmail.com>
Subject: Re: [PATCH 12/12] thunderbolt: Handle DisplayPort tunnel activation asynchronously
Date: Thu, 19 Dec 2024 19:29:50 +0200 [thread overview]
Message-ID: <20241219172950.GI3713119@black.fi.intel.com> (raw)
In-Reply-To: <Z2RR_r_AjyluYNwW@wunner.de>
On Thu, Dec 19, 2024 at 06:03:58PM +0100, Lukas Wunner wrote:
> On Tue, Dec 17, 2024 at 10:22:22AM +0200, Mika Westerberg wrote:
> > In typical cases there is always graphics driver loaded, and also all
> > the cables are connected but for instance in Intel graphics CI they only
> > load the graphics driver after the system is fully booted up. This
> > makes the driver to tear down the DisplayPort tunnel. To help this case
> > we allow passing bigger or indefinite timeout through a new module
> > parameter (dprx_timeout). To keep the driver bit more responsive during
> > that time we change the way DisplayPort tunnels get activated. We first
> > do the normal tunnel setup and then run the polling of DPRX capabilities
> > read completion in a separate worker. This also makes the driver to
> > accept bandwidth requests to already established DisplayPort tunnels
> > more responsive.
>
> Does this mean one has to add that command line option unless i915
> is already loaded on boot (or built-in)? I can easily see i915
> not being in the initrd for some reason but being loaded only
> after the root filesystem is mounted. And that in turn may
> take a while if the user has to enter a password for disk encryption.
> If the user has to add a command line option in such cases I think
> that would be very inconvenient.
Typically no. We wait for the 12s now before tearing down the tunnel and
that should be enough for i915 to kick in and read the capabilities. At
least we did not see any problems during testing. But the command line
option is there as "escape hatch" if defaults don't work.
next prev parent reply other threads:[~2024-12-19 17:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 8:22 [PATCH 00/12] thunderbolt: Improve DisplayPort tunneling Mika Westerberg
2024-12-17 8:22 ` [PATCH 01/12] thunderbolt: Drop doubled empty line from ctl.h Mika Westerberg
2024-12-17 8:22 ` [PATCH 02/12] thunderbolt: Log config space when invalid config space reply is received Mika Westerberg
2024-12-17 8:22 ` [PATCH 03/12] thunderbolt: Debug log an invalid config space reply just once Mika Westerberg
2024-12-17 8:22 ` [PATCH 04/12] thunderbolt: Increase DPRX capabilities read timeout Mika Westerberg
2024-12-17 8:22 ` [PATCH 05/12] thunderbolt: Make tb_tunnel_one_dp() return void Mika Westerberg
2024-12-17 8:22 ` [PATCH 06/12] thunderbolt: Show path name in debug log when path is deactivated Mika Westerberg
2024-12-17 8:22 ` [PATCH 07/12] thunderbolt: Rework how tunnel->[init|deinit] hooks are called Mika Westerberg
2024-12-17 8:22 ` [PATCH 08/12] thunderbolt: Drop tb_tunnel_restart() Mika Westerberg
2024-12-17 8:22 ` [PATCH 09/12] thunderbolt: Pass reason to tb_dp_resource_unavailable() Mika Westerberg
2024-12-17 8:22 ` [PATCH 10/12] thunderbolt: Move forward declarations in one place Mika Westerberg
2024-12-17 8:22 ` [PATCH 11/12] thunderbolt: Rework tb_tunnel_consumed_bandwidth() Mika Westerberg
2024-12-17 8:22 ` [PATCH 12/12] thunderbolt: Handle DisplayPort tunnel activation asynchronously Mika Westerberg
2024-12-19 17:03 ` Lukas Wunner
2024-12-19 17:29 ` Mika Westerberg [this message]
2025-01-03 9:56 ` [PATCH 00/12] thunderbolt: Improve DisplayPort tunneling Mika Westerberg
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=20241219172950.GI3713119@black.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=michael.jamet@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.