All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Deucher <alexdeucher@gmail.com>
To: "Timur Kristóf" <timur.kristof@gmail.com>
Cc: "michael.jamet@intel.com" <michael.jamet@intel.com>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: Why is Thunderbolt 3 limited to 2.5 GT/s on Linux?
Date: Fri, 19 Jul 2019 10:29:30 -0400	[thread overview]
Message-ID: <CADnq5_N++5zcrDM6=NGaMp-CSymfmLw67n2XhEM2g-i4iMg6fw@mail.gmail.com> (raw)
In-Reply-To: <172a41d97d383a8989ebd213bb4230a2df4d636d.camel@gmail.com>

On Thu, Jul 18, 2019 at 10:38 AM Timur Kristóf <timur.kristof@gmail.com> wrote:
>
>
> > >
> > > I took a look at amdgpu_device_get_pcie_info() and found that it
> > > uses
> > > pcie_bandwidth_available to determine the capabilities of the PCIe
> > > port. However, pcie_bandwidth_available gives you only the current
> > > bandwidth as set by the PCIe link status register, not the maximum
> > > capability.
> > >
> > > I think something along these lines would fix it:
> > > https://pastebin.com/LscEMKMc
> > >
> > > It seems to me that the PCIe capabilities are only used in a few
> > > places
> > > in the code, so this patch fixes pp_dpm_pcie. However it doesn't
> > > affect
> > > the actual performance.
> > >
> > > What do you think?
> >
> > I think we want the current bandwidth.  The GPU can only control the
> > speed of its local link.  If there are upstream links that are slower
> > than its local link, it doesn't make sense to run the local link at
> > faster speeds because it will burn extra power it will just run into
> > a
> > bottleneck at the next link.  In general, most systems negotiate the
> > fastest link speed supported by both ends at power up.
> >
> > Alex
>
> Currently, if the GPU connected to a TB3 port, the driver thinks that
> 2.5 GT/s is the best speed that it can use, even though the hardware
> itself uses 8 GT/s. So what the driver thinks is inconsistent with what
> the hardware does. This messes up pp_dpm_pcie.
>
> As far as I understand, PCIe bridge devices can change their link speed
> in runtime based on how they are used or what power state they are in,
> so it makes sense here to request the best speed they are capable of. I
> might be wrong about that.

I don't know of any bridges off hand that change their link speeds on
demand.  That said, I'm certainly not a PCI expert.  Our GPUs for
instance have a micro-controller on them which changes the speed on
demand.  Presumably other devices would need something similar.

>
> If you think this change is undesireable, then maybe it would be worth
> to follow Mika's suggestion and add something along the lines of
> dev->is_thunderbolt so that the correct available bandwidth could still
> be determined.

Ideally, it would be added to the core pci helpers so that each driver
that uses them doesn't have to duplicate the same functionality.

Alex


>
> Tim
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2019-07-19 14:29 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28 10:23 Why is Thunderbolt 3 limited to 2.5 GT/s on Linux? Timur Kristóf
2019-06-28 10:32 ` Mika Westerberg
2019-06-28 11:08   ` Timur Kristóf
2019-06-28 11:34     ` Mika Westerberg
2019-06-28 12:21       ` Timur Kristóf
2019-06-28 12:53         ` Mika Westerberg
2019-06-28 13:33           ` Timur Kristóf
2019-06-28 14:14             ` Mika Westerberg
2019-06-28 14:53               ` Timur Kristóf
2019-07-01 11:44                 ` Mika Westerberg
2019-07-01 14:25                   ` Timur Kristóf
2019-07-01 14:28         ` Alex Deucher
2019-07-01 14:38           ` Timur Kristóf
2019-07-01 14:46             ` Alex Deucher
2019-07-01 15:10               ` Mika Westerberg
2019-07-01 14:54         ` Michel Dänzer
2019-07-01 16:01           ` Timur Kristóf
2019-07-02  8:09             ` Michel Dänzer
2019-07-02  9:49               ` Timur Kristóf
2019-07-03  8:07                 ` Michel Dänzer
2019-07-03 11:04                   ` Timur Kristóf
2019-07-04  8:26                     ` Michel Dänzer
2019-07-05  9:17                       ` Timur Kristóf
2019-07-05 13:36                       ` Alex Deucher
2019-07-18  9:11                         ` Timur Kristóf
2019-07-18 13:50                           ` Alex Deucher
     [not found]                             ` <172a41d97d383a8989ebd213bb4230a2df4d636d.camel@gmail.com>
2019-07-19 14:29                               ` Alex Deucher [this message]
2019-07-03 18:44                   ` Marek Olšák
2019-07-05  9:27                     ` Timur Kristóf
2019-07-05 15:35                       ` Marek Olšák
2019-07-05 16:01                         ` Timur Kristóf
     [not found]                         ` <8f0c2d7780430d40dd1e17a82484d236eae3f981.camel@gmail.com>
2019-07-18 10:29                           ` Michel Dänzer
2019-07-22  9:39                             ` Timur Kristóf
2019-07-23  8:11                               ` Michel Dänzer

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='CADnq5_N++5zcrDM6=NGaMp-CSymfmLw67n2XhEM2g-i4iMg6fw@mail.gmail.com' \
    --to=alexdeucher@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=michael.jamet@intel.com \
    --cc=michel@daenzer.net \
    --cc=mika.westerberg@linux.intel.com \
    --cc=timur.kristof@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.