From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Brad Campbell <lists2009@fnarfbargle.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Apple Thunderbolt Display chaining
Date: Tue, 9 Aug 2022 13:55:05 +0300 [thread overview]
Message-ID: <YvI9Cbin4OKQwZ05@lahna> (raw)
In-Reply-To: <bcebdeb9-4f6a-e931-46f5-b9be899db9a4@fnarfbargle.com>
Hi,
On Tue, Aug 09, 2022 at 06:40:54PM +0800, Brad Campbell wrote:
> G'day Mika,
>
>
> On 9/8/22 18:23, Mika Westerberg wrote:
> > Hi,
> >
> > On Mon, Aug 08, 2022 at 09:27:24PM +0800, Brad Campbell wrote:
> >> If I don't authorize the PCIe tunnels and just leave the DP enabled it
> >> works fine also.
> >
> > But you say that it fails on boot when the driver discovers the tunnels,
> > right? So there is really nothing to authorize (they should be already
> > "authorized" by the boot firmware).
> >
> > If I understand correctly this is how it reproduces (the simplest):
> >
> > 1. Connect a single Apple TB1 display to the system
> > 2. Boot it up
> > 3. Wait a while and it hangs
> >
> > If this is the case, then the driver certainly is not creating any
> > PCIe tunnels itself unless there is a bug somewhere.
> >
> > An additional question, does it reproduce with either TB1 display
> > connected or just with specific TB1 display?
> >
>
> No, I've not been clear enough, I'm sorry. I've re-read what I've written below and
> I'm still not sure I'm clear enough.
>
> The firmware never sets anything up.
>
> When I cold boot the machine (from power on), the thunderbolt displays and tunnels
> remain dark until linux initializes the thunderbolt driver the first time.
>
> If I compile the thunderbolt driver into the kernel, or let the initramfs load it
> the displays come up, all PCIe tunnels are established and everything works.
>
> When I reboot the machine (reset button or warm boot), the firmware continues to
> do nothing and all the tunnels remain in place. The machine dies when the thunderbolt
> driver is loaded for a second time.
>
> That might be a reset/warm boot with it compiled in or loaded from iniramfs.
> It may also be me loading it from the command line after booting with it as a
> module and blacklisted.
>
> The problem comes about when the thunderbolt module is loaded while the PCIe tunnels
> are already established.
>
> To reproduce in the easiest manner I compile the thunderbolt driver as a module and
> blacklist it. This prevents it from auto-loading.
>
> I cold boot the machine, let it boot completely then modprobe thunderbolt and authorize
> the tunnels. I then warm boot which lets the kernel detect and init the DP displays
> and detect/configure all the PCIe devices. The thunderbolt driver is not loaded.
>
> The machine comes up, all tunnels are established and all devices work.
>
> If I then modprobe the thunderbolt driver, things break.
>
> This is the hack in my boot script :
>
> # Spark up thunderbolt
> if [ -z "`grep notb /proc/cmdline`" -a -z "`lsusb | grep '05ac:9227'`" ] ; then
> modprobe thunderbolt
> sleep 1
> echo 1 > /sys/bus/thunderbolt/devices/0-3/authorized
> echo 1 > /sys/bus/thunderbolt/devices/0-303/authorized
> reboot
> fi
Thanks for the clarification! How about on macOS side, does it work (I
would expect yes)?
next prev parent reply other threads:[~2022-08-09 10:55 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <acbb3a86-ea15-47ec-90fa-72fbd94921b1@fnarfbargle.com>
2022-03-29 11:31 ` Apple Thunderbolt Display chaining Mika Westerberg
2022-03-29 12:35 ` Brad Campbell
2022-03-29 13:00 ` Mika Westerberg
2022-03-29 14:06 ` Brad Campbell
2022-03-30 10:18 ` Mika Westerberg
2022-03-30 13:19 ` Brad Campbell
2022-03-30 13:43 ` Mika Westerberg
2022-03-30 14:24 ` Brad Campbell
2022-03-30 14:47 ` Mika Westerberg
2022-03-31 9:02 ` Brad Campbell
2022-03-31 16:36 ` Mika Westerberg
2022-04-01 5:48 ` Brad Campbell
2022-04-01 14:30 ` Mika Westerberg
2022-04-01 15:05 ` Brad Campbell
2022-04-04 10:10 ` Mika Westerberg
2022-04-04 11:38 ` Brad Campbell
2022-04-04 12:53 ` Mika Westerberg
2022-04-06 2:51 ` Brad Campbell
2022-04-06 14:56 ` Mika Westerberg
2022-08-05 7:41 ` Brad Campbell
2022-08-05 11:30 ` Mika Westerberg
2022-08-05 12:43 ` Brad Campbell
2022-08-05 13:01 ` Mika Westerberg
2022-08-05 14:13 ` Brad Campbell
2022-08-05 14:21 ` Mika Westerberg
2022-08-05 14:43 ` Brad Campbell
2022-08-06 6:13 ` Mika Westerberg
2022-08-06 9:41 ` Brad Campbell
2022-08-08 9:51 ` Mika Westerberg
2022-08-08 11:55 ` Brad Campbell
2022-08-08 12:25 ` Brad Campbell
2022-08-08 12:46 ` Mika Westerberg
2022-08-08 13:27 ` Brad Campbell
2022-08-09 10:23 ` Mika Westerberg
2022-08-09 10:40 ` Brad Campbell
2022-08-09 10:55 ` Mika Westerberg [this message]
2022-08-09 11:03 ` Brad Campbell
2022-08-09 11:08 ` Brad Campbell
2022-08-09 14:42 ` Mika Westerberg
2022-08-09 15:16 ` Brad Campbell
2022-08-09 15:50 ` Mika Westerberg
2022-08-10 7:40 ` Brad Campbell
2022-08-11 9:50 ` Mika Westerberg
2022-08-11 14:17 ` Brad Campbell
2022-08-12 9:35 ` Mika Westerberg
2022-08-12 10:16 ` Brad Campbell
2022-08-08 12:42 ` 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=YvI9Cbin4OKQwZ05@lahna \
--to=mika.westerberg@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lists2009@fnarfbargle.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