[PATCH v2 8/9] PCI: Exclude PCIe ports used for tunneling in pcie_bandwidth_available()
Mika Westerberg
mika.westerberg at linux.intel.com
Tue Nov 7 05:45:26 UTC 2023
Hi,
On Mon, Nov 06, 2023 at 07:56:52PM +0100, Lukas Wunner wrote:
> On Mon, Nov 06, 2023 at 12:44:25PM -0600, Mario Limonciello wrote:
> > Tangentially related; the link speed is currently symmetric but there are
> > two sysfs files. Mika left a comment in drivers/thunderbolt/switch.c it may
> > be asymmetric in the future. So we may need to keep that in mind on any
> > design that builds on top of them.
>
> Aren't asymmetric Thunderbolt speeds just a DisplayPort thing?
No, they affect the whole fabric. We have the initial code for
asymmetric switching in v6.7-rc1.
> > As 'thunderbolt' can be a module or built in, we need to bring code into PCI
> > core so that it works in early boot before it loads.
>
> tb_switch_get_generation() is small enough that it could be moved to the
> PCI core. I doubt that we need to make thunderbolt built-in only
> or move a large amount of code to the PCI core.
If at all possible I would like to avoid this and littering PCI side
with non-PCI stuff. There could be other similar "mediums" in the future
where you can transfer packets of "native" protocols such as PCIe so
instead of making it Thunderbolt/USB4 specific it should be generic
enough to support future extensions.
In case of Thunderbolt/USB4 there is no real way to figure out how much
bandwidth each PCIe tunnel gets (it is kind of bulk traffic that gets
what is left from isochronous protocols) so I would not even try that
and instead use the real PCIe links in pcie_bandwidth_available() and
skip all the "virtual" ones.
More information about the amd-gfx
mailing list