search for: egpu

...ndex eef22c6b9665..c2a7fd606c2e 100644 --- a/drivers/gpu/drm/nouveau/nouveau_vga.c +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c @@ -95,6 +95,10 @@ nouveau_vga_init(struct nouveau_drm *drm) vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode); + /* don't register Thunderbolt eGPU with vga_switcheroo */ + if (pci_is_thunderbolt_attached(dev->pdev)) + return; + if (nouveau_runtime_pm == 1) runtime = true; if ((nouveau_runtime_pm == -1) && (nouveau_is_optimus() || nouveau_is_v1_dsm())) @@ -111,6 +115,11 @@ nouveau_vga_fini(struct nouveau_drm *drm) struct d...

...ain? > > Also remind us of the PCI device address of the parent bridge (lspci -vt) > > I'll follow up with more the requested information on bugzilla > (Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069). > > On a quick re-check, it seems to depend on if I used the eGPU before > the initial suspend. If I run glxgears (with DRI_PRIME=1) before suspend it > seems fine. Does the patch ([1]) make things *worse* compared to v4.19-rc5? If so, I'll drop the patch until we figure this out. But if the GPU power issue also occurs in v4.19-rc5, I think we can as...

...--- a/drivers/gpu/drm/nouveau/nouveau_vga.c > +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c > @@ -95,6 +95,10 @@ nouveau_vga_init(struct nouveau_drm *drm) > > vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode); > > + /* don't register Thunderbolt eGPU with vga_switcheroo */ > + if (pci_is_thunderbolt_attached(dev->pdev)) > + return; I guess there's no way to move this inside vga_switcheroo_register_client() instead of putting the test in all the drivers? > + > if (nouveau_runtime_pm == 1) >...

...that's not a problem because on > desktop boxes no handler is registered and thus vga_switcheroo_enable() > is never called. Hybrid graphics laptops on the other hand do register > a handler, but are assumed to never register more than one discrete GPU. > However once a Thunderbolt eGPU is attached to a hybrid graphics laptop, > that assumption is no longer true and things go south when vga_switcheroo > runtime suspends the external discrete GPU and then calls the handler to > cut power to the internal discrete GPU. The driver for the internal GPU > will sit there puz...

...if it's found save it >> into a new `is_virtual_link` bit in `struct pci_device`. > > While this is fine for the "first" tunneled link, this does not take > into account possible other "virtual" links that lead to the endpoint in > question. Typically for eGPU it only makes sense to plug it directly to > the host but say there is a USB4 hub (with PCIe tunneling capabilities) > in the middle. Now the link from the hub to the eGPU that is also > "virtual" is not marked as such and the bandwidth calculations may not > get what is expec...

...ne discrete GPU but that's not a problem because on desktop boxes no handler is registered and thus vga_switcheroo_enable() is never called. Hybrid graphics laptops on the other hand do register a handler, but are assumed to never register more than one discrete GPU. However once a Thunderbolt eGPU is attached to a hybrid graphics laptop, that assumption is no longer true and things go south when vga_switcheroo runtime suspends the external discrete GPU and then calls the handler to cut power to the internal discrete GPU. The driver for the internal GPU will sit there puzzled and typically c...

...g because I tried your patches on my setup in the hope they'd fix my lockups. Unfortunately they didn't, so I'm offering debug assistance to make my system work as well. Here's my setup: - Arch Linux - Lenovo Thinkpad x230 laptop with integrated intel (ivy bridge) - External GPU (eGPU) connected via ExpressCard <-> PCIe adaptor, a nvidia GeForce 650 Ti (Kepler). The PCIe link is unfortunately limited to Gen 1 and one lane. - PRIME with eGPU as primary (following this guide: https://wiki.archlinux.org/index.php/PRIME#Discrete_Card_as_Primary_GPU) - This setup works fine...

...o remind us of the PCI device address of the parent bridge (lspci -vt) >> >> I'll follow up with more the requested information on bugzilla >> (Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069). >> >> On a quick re-check, it seems to depend on if I used the eGPU before >> the initial suspend. If I run glxgears (with DRI_PRIME=1) before suspend it >> seems fine. > > Does the patch ([1]) make things *worse* compared to v4.19-rc5? > No, certainly not. It does look like a different issue since resuming now works at least if I used the e...

On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel at rockbox.org> wrote: > The latest iteration does not work on my HP system. The GPU fails to > power up just like the unpatched kernel. That's weird, I would not expect a behaviour change in the latest patch. pci_restore_config_dword() has some debug messages, could you please make them visible and show logs again? Also remind

...blem because on > > desktop boxes no handler is registered and thus vga_switcheroo_enable() > > is never called. Hybrid graphics laptops on the other hand do register > > a handler, but are assumed to never register more than one discrete GPU. > > However once a Thunderbolt eGPU is attached to a hybrid graphics laptop, > > that assumption is no longer true and things go south when vga_switcheroo > > runtime suspends the external discrete GPU and then calls the handler to > > cut power to the internal discrete GPU. The driver for the internal GPU > &gt...

...;pdev) > + if (!dev_is_pci(dev->dev)) > return; > + pdev = to_pci_dev(dev->dev); > > - vga_client_register(dev->pdev, dev, NULL, nouveau_vga_set_decode); > + vga_client_register(pdev, dev, NULL, nouveau_vga_set_decode); > > /* don't register Thunderbolt eGPU with vga_switcheroo */ > - if (pci_is_thunderbolt_attached(dev->pdev)) > + if (pci_is_thunderbolt_attached(pdev)) > return; > > - vga_switcheroo_register_client(dev->pdev, &nouveau_switcheroo_ops, runtime); > + vga_switcheroo_register_client(pdev, &nouveau_switc...

...visible and show logs again? > Also remind us of the PCI device address of the parent bridge (lspci -vt) > I'll follow up with more the requested information on bugzilla (Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069). On a quick re-check, it seems to depend on if I used the eGPU before the initial suspend. If I run glxgears (with DRI_PRIME=1) before suspend it seems fine. Best regards.

The wrong values are reported from pcie_bandwidth_available() which can cause problems for performance of eGPUs. This series overhauls Thunderbolt related device detection and uses the changes to change the behavior of pcie_bandwidth_available(). v2->v3: * Stop lumping all thunderbolt VSEC and USB4 devices together, introduce is_virtual_link instead * Drop unnecessary patches Mario Limonciello (7...

this series solves different issues we encounter on kepler cards while reclocking: 1. core clock doesn't change at all and produces a volting error (patch 1) this can happen when the voltage table has only 0ed values in the header so we have to parse the entries itself, which contain the right voltages 2. kepler won't clock to highest cstates (patch 2) this happens, because there are

From: Sui Jingfeng <suijingfeng at loongson.cn> Patch 1,2 and 3 do basic clean up to the vgaarb module. Patch 4 introduce is_boot_device function callback to vga_client_register Sui Jingfeng (4): PCI/VGA: tidy up the code and comment format PCI/VGA: Use unsigned type for the io_state variable PCI/VGA: only deal with VGA class devices PCI/VGA: introduce is_boot_device function

From: Sui Jingfeng <suijingfeng at loongson.cn> To keep consistent with vga_iostate_to_str() function, the third argument of vga_str_to_iostate() function should be 'unsigned int *'. Signed-off-by: Sui Jingfeng <suijingfeng at loongson.cn> --- drivers/pci/vgaarb.c | 29 +++++++++++++++-------------- include/linux/vgaarb.h | 8 +++----- 2 files changed, 18 insertions(+),

From: Sui Jingfeng <suijingfeng at loongson.cn> Currently, the default VGA device selection is not perfect. Potential problems are: 1) This function is a no-op on non-x86 architectures. 2) It does not take the PCI Bar may get relocated into consideration. 3) It is not effective for the PCI device without a dedicated VRAM Bar. 4) It is device-agnostic, thus it has to waste the effort to

From: Sui Jingfeng <suijingfeng at loongson.cn> On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to hook up with this stub by calling the vga_client_register() function. Once the