From: Brad Campbell <lists2009@fnarfbargle.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Apple Thunderbolt Display chaining
Date: Tue, 9 Aug 2022 18:40:54 +0800 [thread overview]
Message-ID: <bcebdeb9-4f6a-e931-46f5-b9be899db9a4@fnarfbargle.com> (raw)
In-Reply-To: <YvI1lQh+C0SJiG73@lahna>
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
Regards,
Brad
next prev parent reply other threads:[~2022-08-09 10:41 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 ` 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 [this message]
2022-08-09 10:55 ` Mika Westerberg
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=bcebdeb9-4f6a-e931-46f5-b9be899db9a4@fnarfbargle.com \
--to=lists2009@fnarfbargle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.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
all inboxes | Powered by JetHome®