All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Stefan Hoffmeister <stefan.hoffmeister@gmail.com>
Cc: "Tomasz Moń" <desowin@gmail.com>,
	"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
	linux-usb@vger.kernel.org
Subject: Re: Thunderbolt: One missing DisplayPort?
Date: Wed, 1 Jun 2022 13:51:36 +0300	[thread overview]
Message-ID: <YpdEuAIRABoad0eU@lahna> (raw)
In-Reply-To: <CALhB_QOCJfxoDpNmRi-YEKozeAh4PMZeVy3avhzR7jVcvWfXYg@mail.gmail.com>

Hi,

On Tue, May 31, 2022 at 09:45:55PM +0200, Stefan Hoffmeister wrote:
> What could be reasons that the second tunnel is not established on the
> Dell? I read somewhere that Intel hands off the firmware to vendors
> (Dell) who then customize it for their systems? Could the vendor have
> made bad customizations / configurations of that package while
> integrating it?

Probably not a firmware issue.

> I would imagine that plugging in a DisplayPort cable makes the dock
> (firmware) signal something to the notebook (TB firmware) and a
> negotiation will take place. That negotiation fails, otherwise the
> tunnel would be established, and remain established? Is there a means
> to trace the negotiation?

It is all done in firmware but when you plug in DisplayPort cable to the
dock, it generates a hotplug event for that DP OUT adapter and this will
then be handled by the firmware connection manager by establishing a DP
tunnel (if it finds resources).

> FWIW, I have read the phrase "insufficent provision of GPU Interfaces
> to the TB port" (sic, on Reddit), and a lengthy related post at
> https://www.dell.com/community/XPS/Understanding-Thunderbolt-docks-GPU-bandwidth-and-GPU-interfaces/td-p/7678776
> which I will not pretend to understand.
> 
> What I wonder about is whether the "GPU interfaces" situation would be
> reliably discoverable by inspecting ... something ... anything?
> 
> Anyway, my impression, from a layering point of view, is that on the
> stack (my imagination!)
> 
> * notebook hardware
> * firmware (BIOS, Thunderbolt firmware / connection manager, ...)
> * Linux thunderbolt driver
> * Linux graphics drivers: drm / kms (i915 / nvidia / nouveau)
> 
> the graphics drivers are not involved when it comes to building /
> maintaining the Thunderbolt(!) tunnel?

Correct.

> I am also reading "Thunderbolt Alternate Mode encapsulates DisplayPort
> Alternate Mode". To my ears this sounds like "wrap the raw DisplayPort
> Alternate Mode bitstream", just with more bandwidth. Pure "DisplayPort
> Alternate Mode" I can force with success by way of disabling
> Thunderbolt in the BIOS (at the expense of bandwidth -> bad refresh
> rate). And "DisplayPort Alternate Mode" gives me _both_ screens,
> apparently very much scraping along at the max protocol bandwidth,
> with the 4K screen going black (out of sync?) every once in a while.
> 
> Sorry for my rambling, this is an area where I have no expertise.
> 
> Anyway, if those graphics drivers are involved for _Thunderbolt_,
> please do tell me, and I'll venture over to dri-devel.

In case of firmware based connection manager, the Thunderbolt driver
does not do much. Pretty much just the PCIe tunnel authorization and
power management things (and P2P).

IIRC this non-working system had a discrete (NVIDIA?) GPU? It may be
that routing it to the DP IN adapters in the Thunderbolt host router
requires something we don't implement in Linux side yet.

> And given what I see above, is that still "Thunderbolt 4 Certified"
> ("Two 4K displays") in the case of the Dell Inspiron 7610?

This I don't know I would expect Dell testing this, at least with their
own dock.

  reply	other threads:[~2022-06-01 10:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-20 10:22 Thunderbolt: One missing DisplayPort? Stefan Hoffmeister
2022-05-24 10:55 ` Heikki Krogerus
2022-05-24 11:04   ` Mika Westerberg
2022-05-27  6:24     ` Stefan Hoffmeister
2022-05-27  9:10       ` Mika Westerberg
2022-05-28 14:29         ` Stefan Hoffmeister
2022-05-29 19:51         ` Stefan Hoffmeister
2022-05-30  8:33           ` Tomasz Moń
2022-05-30  9:54             ` Mika Westerberg
2022-05-30 18:57               ` Stefan Hoffmeister
2022-05-31  9:36                 ` Mika Westerberg
2022-05-31 19:45                   ` Stefan Hoffmeister
2022-06-01 10:51                     ` Mika Westerberg [this message]
2022-06-02 19:34               ` Tomasz Moń
2022-06-03  5:04                 ` Mika Westerberg
2022-06-08 14:27                   ` Tomasz Moń
2022-06-11 16:29                     ` Tomasz Moń
2022-06-07 17:28                 ` Stefan Hoffmeister
2022-05-30 18:02             ` Stefan Hoffmeister

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=YpdEuAIRABoad0eU@lahna \
    --to=mika.westerberg@linux.intel.com \
    --cc=desowin@gmail.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=stefan.hoffmeister@gmail.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.