Re: [PATCH v1 1/1] treewide: Align match_string() with sysfs_match_string()

h_string(ecrc_policy_str, ARRAY_SIZE(ecrc_policy_str), str); > + i = match_string(ecrc_policy_str, str); > if (i < 0) > return; > Acked-by: Bjorn Helgaas# drivers/pci/ > +++ b/mm/vmpressure.c > @@ -388,7 +388,7 @@ int vmpressure_register_event(str

Re: [Nouveau] [PATCH v2 0/9] Improvements to pcie_bandwidth_available() for eGPUs

On Fri, Nov 03, 2023 at 02:07:49PM -0500, Mario Limonciello wrote: > Downstream drivers are getting the wrong values from > pcie_bandwidth_available() which is causing problems for performance > of eGPUs. > > This series overhauls Thunderbolt related device detection and uses > the changes to

Re: [Nouveau] [PATCH 0/5] Add the pci_get_base_class() helper and use it

On Fri, Aug 25, 2023 at 02:27:09PM +0800, Sui Jingfeng wrote: > From: Sui Jingfeng > > There is no function that can be used to get all PCI(e) devices in a > system by matching against its the PCI base class code only, while keep > the sub-class code and the programming interface ignored.

Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

On Fri, Jun 30, 2023 at 10:14:11AM +0800, suijingfeng wrote: > On 2023/6/30 01:44, Limonciello, Mario wrote: > > > On 2023/6/29 23:54, Bjorn Helgaas wrote: > > > > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote: > > > > 4) Right now we're in the

Re: [Nouveau] [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote: > Hi, > > > A nouveau developer(Lyude) from redhat send me a R-B, > > Thanks for the developers of nouveau project. > > > Please allow me add a link[1] here. > > > [1] >

Re: [Nouveau] [Intel-gfx] [PATCH v3 4/4] PCI/VGA: introduce is_boot_device function callback to vga_client_register

On Fri, Jun 09, 2023 at 10:27:39AM +0800, Sui Jingfeng wrote: > On 2023/6/9 03:19, Bjorn Helgaas wrote: > > On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote: > > > From: Sui Jingfeng > > > > > > The vga_is_firmware_default() function is arch-depend

Re: [Nouveau] [Intel-gfx] [PATCH v3 4/4] PCI/VGA: introduce is_boot_device function callback to vga_client_register

On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote: > From: Sui Jingfeng > > The vga_is_firmware_default() function is arch-dependent, which doesn't > sound right. At least, it also works on the Mips and LoongArch platforms. > Tested with the drm/amdgpu and drm/radeon drivers. However,

Re: [Nouveau] [Intel-gfx] [PATCH v3 3/4] PCI/VGA: only deal with VGA class devices

Start with verb and capitalize to match ("Deal only with ...") On Thu, Jun 08, 2023 at 07:43:21PM +0800, Sui Jingfeng wrote: > From: Sui Jingfeng > > vgaarb only deal with the VGA devcie(pdev->class == 0x0300), so replace the > pci_get_subsys() function with pci_get_class(). Filter the non pci

Re: [Nouveau] [Intel-gfx] [PATCH v3 1/4] PCI/VGA: tidy up the code and comment format

Capitalize subject to match ("Tidy ...") On Thu, Jun 08, 2023 at 07:43:19PM +0800, Sui Jingfeng wrote: > From: Sui Jingfeng > > This patch replaces the leading space with a tab and removes the double > blank line, no functional change. Can you move this to the end of the series? The

Re: [Nouveau] [Intel-gfx] [PATCH v2 1/2] vgaarb: various coding style and comments fix

Match the subject line style: $ git log --oneline drivers/pci/vgaarb.c f321c35feaee PCI/VGA: Replace full MIT license text with SPDX identifier d5109fe4d1ec PCI/VGA: Use unsigned format string to print lock counts 4e6c91847a7f PCI/VGA: Log bridge control messages when adding devices

Re: [Nouveau] [PATCH] PCI: stop spamming info in quirk_nvidia_hda

a pci_info_once() sort of thing? I think there's some value in knowing that we're changing the BIOS configuration outside the purview of a driver, since I assume BIOS had some reason for hiding the HDA controller. > Cc: Bjorn Helgaas > Cc: Lukas Wunner > Cc: linux-...@vger

Re: [Nouveau] [PATCH v5 3/7] PCI: Drop the `is_thunderbolt` attribute from PCI core

On Mon, Feb 28, 2022 at 03:33:13PM +, Limonciello, Mario wrote: > [AMD Official Use Only] > > > > > On Fri, Feb 25, 2022 at 11:42:24AM -0600, Bjorn Helgaas wrote: > > > That would just leave the "PCI_VSEC_ID_INTEL_TBT implies external- > > facin

Re: [Nouveau] [PATCH v5 3/7] PCI: Drop the `is_thunderbolt` attribute from PCI core

On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote: > The `is_thunderbolt` attribute originally had a well defined list of > quirks that it existed for, but it has been overloaded with more > meaning. > > Instead use the driver core removable attribute to indicate the > detail a

Re: [Nouveau] [PATCH v5 3/7] PCI: Drop the `is_thunderbolt` attribute from PCI core

On Thu, Feb 24, 2022 at 07:23:49PM -0600, Bjorn Helgaas wrote: > On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote: > > The `is_thunderbolt` attribute originally had a well defined list of > > quirks that it existed for, but it has been overloaded with m

Re: [Nouveau] [PATCH v5 3/7] PCI: Drop the `is_thunderbolt` attribute from PCI core

On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote: > The `is_thunderbolt` attribute originally had a well defined list of > quirks that it existed for, but it has been overloaded with more > meaning. > > Instead use the driver core removable attribute to indicate the > detail a

Re: [Nouveau] [PATCH v3 05/12] PCI: Detect root port of internal USB4 devices by `usb4-host-interface`

On Mon, Feb 14, 2022 at 12:56:58PM +0200, Mika Westerberg wrote: > On Mon, Feb 14, 2022 at 09:52:02AM +0100, Lukas Wunner wrote: > > On Mon, Feb 14, 2022 at 09:34:26AM +0200, Mika Westerberg wrote: > > > On Fri, Feb 11, 2022 at 03:45:46PM -0600, Bjorn Helgaas wrote: >

Re: [Nouveau] [PATCH v3 07/12] PCI: Set ports for discrete USB4 controllers appropriately

Make the subject specific, not just "appropriately." I think you're marking something *removable*, so include that. On Fri, Feb 11, 2022 at 01:32:45PM -0600, Mario Limonciello wrote: > Discrete USB4 controllers won't have ACPI nodes specifying which > PCIe or XHCI port they are linked with. > >

Re: [Nouveau] [PATCH v3 06/12] PCI: Explicitly mark USB4 NHI devices as removable

On Fri, Feb 11, 2022 at 01:32:44PM -0600, Mario Limonciello wrote: > USB4 class devices are also removable like Intel Thunderbolt devices. Spec reference, please. > Drivers of downstream devices use this information to declare functional > differences in how the drivers perform by knowing that

Re: [Nouveau] [PATCH v3 05/12] PCI: Detect root port of internal USB4 devices by `usb4-host-interface`

On Fri, Feb 11, 2022 at 01:32:43PM -0600, Mario Limonciello wrote: > The root port used for PCIe tunneling should be marked as removable to > ensure that the entire chain is marked removable. > > This can be done by looking for the device property specified in > the ACPI tables

Re: [Nouveau] [PATCH v3 03/12] PCI: Move check for old Apple Thunderbolt controllers into a quirk

On Fri, Feb 11, 2022 at 01:32:41PM -0600, Mario Limonciello wrote: > `pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt > controller to indicate that D3 is possible. As this is used solely > for older Apple systems, move it into a quirk that enumerates across > all Intel TBT

Re: [Nouveau] [PATCH v3 02/12] PCI: Move `is_thunderbolt` check for lack of command completed to a quirk

Update subject to something like: PCI: pciehp: Quirk broken Command Completed support on Intel Thunderbolt controllers On Fri, Feb 11, 2022 at 01:32:40PM -0600, Mario Limonciello wrote: > The `is_thunderbolt` check is currently used to indicate the lack of > command completed support for a

Re: [Nouveau] [PATCH v3 01/12] thunderbolt: move definition of PCI_CLASS_SERIAL_USB_USB4

> Acked-by: Alex Deucher > Acked-by: Mika Westerberg > Signed-off-by: Mario Limonciello I would change the subject to: PCI: Add USB4 class definition because this seems like more of a PCI thing than a Thunderbolt thing, but either way: Acked-by: Bjorn Helgaas > --- &g

Re: [Nouveau] 5.12.1 0010:nvkm_falcon_v1_wait_for_halt+0x8f/0xb9 [nouveau]

[+cc Ben] Hi Marc, Thanks for paying attention to these things. I added Ben (who probably would see this via nouveau@lists.freedesktop.org anyway). I don't see a PCI issue here, but the nouveau timeout, which I know nothing about, does look like it could be interesting. On Wed, May 05, 2021 at

Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)

On Thu, Jan 28, 2021 at 04:56:26PM -0800, Marc MERLIN wrote: > On Wed, Jan 27, 2021 at 03:33:00PM -0600, Bjorn Helgaas wrote: > > Hi Marc, I appreciate your persistence on this. I am frankly > > surprised that you've put up with this so long. > > Well, been using linux f

Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)

On Wed, Jan 27, 2021 at 03:33:02PM -0600, Bjorn Helgaas wrote: > On Sat, Dec 26, 2020 at 03:12:09AM -0800, Marc MERLIN wrote: > > This started with 5.5 and hasn't gotten better since then, despite > > some reports I tried to send. > > > > As per my previous message

Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)

Hi Marc, I appreciate your persistence on this. I am frankly surprised that you've put up with this so long. On Sat, Dec 26, 2020 at 03:12:09AM -0800, Marc MERLIN wrote: > This started with 5.5 and hasn't gotten better since then, despite > some reports I tried to send. > > As per my previous

[Nouveau] add nouveau to lore?

Is there any chance the nouveau mailing list (https://lists.freedesktop.org/archives/nouveau/) could be added to lore? Threads like this conversation: https://lore.kernel.org/r/20200908002935.gd20...@merlins.org get harder to browse when mailing lists that *are* on lore get removed from cc.

Re: [Nouveau] nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

On Fri, Jul 24, 2020 at 12:57:51PM +0300, Mika Westerberg wrote: > On Thu, Jul 23, 2020 at 10:30:58PM +0200, Karol Herbst wrote: > > On Wed, Jul 22, 2020 at 11:25 AM Mika Westerberg > > wrote: > > > > > > On Tue, Jul 21, 2020 at 01:37:12PM -0500, Patrick Volkerding wrote: > > > > On 7/21/20 10:27

Re: [Nouveau] nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

On Fri, Jul 17, 2020 at 10:43:18AM -0400, Sasha Levin wrote: > On Fri, Jul 17, 2020 at 02:43:52AM +0200, Karol Herbst wrote: > > On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote: > > > On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote: > > > > On Tue

Re: [Nouveau] nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

[+cc Sasha -- stable kernel regression] [+cc Patrick, Kai-Heng, LKML] On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote: > On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote: > > > > Hi everybody, > > > > with the mentioned commit Nouveau isn't able to load firmware onto the > > GPU on

Re: [Nouveau] [PATCH v3] PCI: Use ioremap(), not phys_to_virt() for platform ROM

On Mon, Mar 30, 2020 at 01:54:33PM +, Deucher, Alexander wrote: > > -Original Message- > > From: Bjorn Helgaas > > Sent: Saturday, March 28, 2020 4:19 PM > > To: Mikel Rychliski > > Cc: amd-...@lists.freedesktop.org; linux-...@vger.kernel.org; >

Re: [Nouveau] [PATCH v3] PCI: Use ioremap(), not phys_to_virt() for platform ROM

viously directly accessed an __iomem > pointer. Avoid this by calling memcpy_fromio() instead of kmemdup(). > > pci_platform_rom() now has no remaining callers, so remove it. > > Signed-off-by: Mikel Rychliski I applied this to pci/resource for v5.7. I would feel better if some of the

Re: [Nouveau] [PATCH v7] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

On Tue, Mar 24, 2020 at 06:31:08PM +0100, Karol Herbst wrote: > On Sat, Mar 21, 2020 at 2:02 AM Karol Herbst wrote: > > > > On Fri, Mar 20, 2020 at 11:19 PM Bjorn Helgaas wrote: > > > > > > On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote: > >

Re: [Nouveau] [PATCH v7] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

On Sat, Mar 21, 2020 at 02:02:22AM +0100, Karol Herbst wrote: > On Fri, Mar 20, 2020 at 11:19 PM Bjorn Helgaas wrote: > > > > On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote: > > > Fixes the infamous 'runtime PM' bug many users are facing on Laptops with

Re: [Nouveau] [PATCH v7] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote: > Fixes the infamous 'runtime PM' bug many users are facing on Laptops with > Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. > > Depending on the used kernel there might be messages like those in demsg: > >

Re: [Nouveau] [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

[+cc Daniel, Vidya, Thierry; thread starts at https://lore.kernel.org/r/20191017121901.13699-1-kher...@redhat.com] On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote: > On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas wrote: > > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Kar

Re: [Nouveau] [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

elow straightened out. > Signed-off-by: Karol Herbst > Cc: Bjorn Helgaas > Cc: Lyude Paul > Cc: Rafael J. Wysocki > Cc: Mika Westerberg > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Cc: nouveau@lists.fr

Re: [Nouveau] [PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

On Wed, Oct 16, 2019 at 11:48:22PM +0200, Karol Herbst wrote: > On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas wrote: > > On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote: > > > but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the > > > platform

Re: [Nouveau] [PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

ould weigh in on. I don't know why we set the device to D3hot with PCI_PM_CTRL before using the ACPI methods, and I don't know what the effect of skipping that is. It seems a little messy to slice out this tiny piece from the middle, but maybe it makes sense. > On Wed, Oct 16, 2019 at 9:14 PM Bj

Re: [Nouveau] [PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

t only for certain combinations of intel and nvidia hardware > > Signed-off-by: Karol Herbst > Cc: Bjorn Helgaas > Cc: Lyude Paul > Cc: Rafael J. Wysocki > Cc: Mika Westerberg > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: dri-de...@lists.freede

Re: [Nouveau] [RFC PATCH] pci: prevent putting pcie devices into lower device states on certain intel bridges

On Tue, Oct 01, 2019 at 06:21:28PM +0200, Karol Herbst wrote: > On Tue, Oct 1, 2019 at 3:27 PM Bjorn Helgaas wrote: > > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote: > > > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg > > > wrote: > > > >

Re: [Nouveau] [RFC PATCH] pci: prevent putting pcie devices into lower device states on certain intel bridges

On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote: > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg > wrote: > > > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote: > > > still happens with your patch applied. The machine simply gets shut down. > > > > > > dmesg can be

Re: [Nouveau] [RFC PATCH] pci: prevent putting pcie devices into lower device states on certain intel bridges

d learn a lot of useful python by studying it. > Signed-off-by: Karol Herbst > Cc: Bjorn Helgaas > Cc: Lyude Paul > Cc: linux-...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Cc: nouveau@lists.freedesktop.org > --- > drivers/pci/pci.c | 39 +++

Re: [PATCH] PCI: Use pci_reset_bus() in quirk_reset_lenovo_thinkpad_50_nvgpu()

us() instead which properly > resets the GPU bus and all device functions under it, including both the > GPU and the HDA controller. > > Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers") > Cc: Lukas Wunner > Cc: Daniel Drake > Cc: Bjorn Helgaas > Cc: Aaron Pl

Re: [Nouveau] [PATCH v2] PCI: Expose hidden NVIDIA HDA controllers

051744.24039-1-dr...@endlessm.com Link: https://devtalk.nvidia.com/default/topic/1024022 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75985 Signed-off-by: Lukas Wunner Signed-off-by: Daniel Drake [bhelgaas: commit log, log message, return early if already enabled] Sig

Re: [Nouveau] [PATCH] PCI: Expose hidden NVIDIA HDA controllers

[+cc Rafael, Martin, zigarrre] On Thu, Jun 13, 2019 at 02:35:14PM +0800, Daniel Drake wrote: > From: Lukas Wunner > > The integrated HDA controller on Nvidia GPUs can be hidden with a bit in > the GPU's config space. Information about this scheme was provided by > NVIDIA on their forums. > >

Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini

0 00 00 00 00 00 00 00 00 > > > 70: 00 00 00 00 00 00 00 00 00 62 17 00 00 00 00 0a > > > 80: 01 90 03 c8 08 00 00 00 0d 80 00 00 28 10 be 07 > > > 90: 05 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > a0: 10 00 42 01 01 80 00 00 20 00 00 00 03 ad 61 02 > &

Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini

On Tue, May 21, 2019 at 03:28:48PM +0200, Karol Herbst wrote: > On Tue, May 21, 2019 at 3:11 PM Bjorn Helgaas wrote: > > On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote: > > > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas wrote: > > > > On Tue, Ma

Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini

On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote: > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas wrote: > > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > > > Apperantly things go south if we suspend the device with a different PCIE > > >

Re: [Nouveau] [PATCH v2 2/4] pci: enable pcie link changes for pascal

On Tue, May 07, 2019 at 10:12:43PM +0200, Karol Herbst wrote: > Signed-off-by: Karol Herbst > Reviewed-by: Lyude Paul > --- > drm/nouveau/nvkm/subdev/pci/gk104.c | 8 > drm/nouveau/nvkm/subdev/pci/gp100.c | 10 ++ > drm/nouveau/nvkm/subdev/pci/priv.h | 5 + > 3 files

Re: [Nouveau] [PATCH v2 4/4] pci: save the boot pcie link speed and restore it on fini

On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote: > Apperantly things go south if we suspend the device with a different PCIE > link speed set than it got booted with. Fixes runtime suspend on my gp107. > > This all looks like some bug inside the pci subsystem and I would prefer a >

Re: [Nouveau] [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote: > On a very specific subset of ThinkPad P50 SKUs, particularly ones that > come with a Quadro M1000M chip instead of the M2000M variant, the BIOS > seems to have a very nasty habit of not always resetting the secondary > Nvidia GPU

Re: [Nouveau] [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

On Wed, Apr 24, 2019 at 03:16:37PM -0400, Lyude Paul wrote: > On Wed, 2019-04-24 at 13:59 -0500, Bjorn Helgaas wrote: > > Not being a scheduled work expert, I was unsure if this experiment was > > equivalent to what I proposed. > > > > I'm always suspicious of singleton

Re: [Nouveau] [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

On Mon, Apr 15, 2019 at 02:07:18PM -0400, Lyude Paul wrote: > On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote: > > [+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) > > resume")] > > > > On Fri, Mar 22, 2019 at 06:30:15AM -05

Re: [Nouveau] [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

On Wed, Apr 24, 2019 at 01:31:09PM -0400, Lyude Paul wrote: > Any update on this? This has been waiting for a while now Oh, sorry, I guess we were both waiting for the other. Let me respond to the email with context. > On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote: > &g

Re: [Nouveau] [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

[+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) resume")] On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote: > On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote: > > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul

[Nouveau] [PATCH] drm/nouveau: Remove duplicate ACPI_VIDEO_NOTIFY_PROBE definition

From: Bjorn Helgaas Commit 3a6536c51d5d ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE") added a definition of ACPI_VIDEO_NOTIFY_PROBE because didn't supply one. Later, commit eff4a751cce5 ("ACPI / video: Move ACPI_VIDEO_NOTIFY_* defines to acpi/video.h") moved ACP

Re: [Nouveau] [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote: > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote: > > On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote: > > > On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote: > > > > On Tue, Fe

Re: [Nouveau] [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

[+cc Rafael] On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote: > On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote: > > On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote: > > > On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote: > > >

Re: [Nouveau] [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

On Mon, Feb 18, 2019 at 3:14 PM Sasha Levin wrote: > > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.20.8,

Re: [Nouveau] [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

Hi Lyude, On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote: > On a very specific subset of ThinkPad P50 SKUs, particularly ones that > come with a Quadro M1000M chip instead of the M2000M variant, the BIOS > seems to have a very nasty habit of not always resetting the secondary > Nvidia

Re: [Nouveau] [PATCH v3] PCI: Reprogram bridge prefetch registers on resume

On Tue, Oct 2, 2018 at 4:27 PM Thomas Martitz wrote: > > Am 02.10.18 um 22:03 schrieb Bjorn Helgaas: > > Hi Thomas, > > > > On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote: > >> Am 01.10.18 um 06:57 schrieb Daniel Drake: > >>> On Sun,

Re: [Nouveau] [PATCH v3] PCI: Reprogram bridge prefetch registers on resume

Hi Thomas, On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote: > Am 01.10.18 um 06:57 schrieb Daniel Drake: > > On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz wrote: > > > The latest iteration does not work on my HP system. The GPU fails to > > > power up just like the unpatched

Re: [Nouveau] [PATCH v3] PCI: Reprogram bridge prefetch registers on resume

[+cc LKML] On Tue, Sep 18, 2018 at 04:32:44PM -0500, Bjorn Helgaas wrote: > On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote: > > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > > after S3 suspend/resume. The affected products include multiple

Re: [Nouveau] [PATCH v3] PCI: Reprogram bridge prefetch registers on resume

On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote: > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > after S3 suspend/resume. The affected products include multiple > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > many errors such as: > >

Re: [Nouveau] [PATCH] PCI: Reprogram bridge prefetch registers on resume

[+cc LKML, Dave, Luming] On Fri, Sep 07, 2018 at 05:05:15PM +0200, Peter Wu wrote: > On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote: > <..> > > Thomas Martitz reports that this workaround also solves an issue where > > the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is

Re: [Nouveau] [PATCH] PCI: Reprogram bridge prefetch registers on resume

[+cc LKML] On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote: > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > after S3 suspend/resume. The affected products include multiple > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > many errors such

Re: [Nouveau] [PATCH] PCI: add prefetch quirk to work around Asus/Nvidia suspend issues

[+cc Intel folks] On Fri, Aug 31, 2018 at 03:30:57PM +0800, Daniel Drake wrote: > On over 40 Intel-based Asus products, the nvidia GPU becomes unusable > after S3 suspend/resume. The affected products include multiple > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > many

Re: [Nouveau] [PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA

On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote: > On Tue, Mar 06, 2018 at 11:29:40AM +0100, Daniel Vetter wrote: > > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote: > > > Modernize vga_switcheroo by using a device link to enforce a runtime PM > > > dependency from an

Re: [Nouveau] [PATCH v2 1/7] PCI: Restore config space on runtime resume despite being unbound

r's BARs will be > uninitialized when a driver later probes it. > > Fix by saving and restoring config space over a runtime suspend cycle > even if the device is not bound. > > Cc: Bjorn Helgaas <bhelg...@google.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso..

Re: [Nouveau] [PATCH 5/7] vga_switcheroo: Use device link for HDA controller

[+cc George] On Fri, Feb 23, 2018 at 10:51:47AM +0100, Lukas Wunner wrote: > On Tue, Feb 20, 2018 at 04:20:59PM -0600, Bjorn Helgaas wrote: > > On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote: > > > The device link is added in a PCI quirk rather t

Re: [Nouveau] [PATCH 2/7] PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public

rarchy again and wake all devices, causing them to > be put into D0active and then letting them autosuspend as they see fit. > > To this end make pci_wakeup_bus() & pci_bus_set_current_state() public > so PCI drivers don't have to reinvent the wheel. > > Cc: Bjorn Helg

Re: [Nouveau] [PATCH 5/7] vga_switcheroo: Use device link for HDA controller

o is true. > > For more information on device links please refer to: > https://www.kernel.org/doc/html/latest/driver-api/device_link.html > Documentation/driver-api/device_link.rst > > Cc: Dave Airlie <airl...@redhat.com> > Cc: Ben Skeggs <bske...@redhat.com> > Cc: Takashi Iw

Re: [Nouveau] [PATCH 1/7] PCI: Restore BARs on runtime resume despite being unbound

suspend may show different things, which seems counter-intuitive. I wouldn't think of a full-blown restore as "inflating the code"; I would think of it as "having fewer special cases", i.e., we always use the same restore path instead of having the main one plus a special one

Re: [Nouveau] [PATCH v1] ACPI: Switch to use generic UUID API

m> > Cc: Ben Skeggs <bske...@redhat.com> > Cc: Benjamin Tissoires <benjamin.tissoi...@redhat.com> > Cc: Joerg Roedel <j...@8bytes.org> > Cc: Adrian Hunter <adrian.hun...@intel.com> > Cc: Yisen Zhuang <yisen.zhu...@huawei.com> > Cc: Bjorn Helgaas &

Re: [Nouveau] [PATCH 1/5] PCI: Recognize Thunderbolt devices

On Sat, Feb 25, 2017 at 08:40:03AM +0100, Lukas Wunner wrote: > On Fri, Feb 24, 2017 at 04:17:24PM -0600, Bjorn Helgaas wrote: > > On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote: > > > --- a/include/linux/pci.h > > > +++ b/include/linux/pci.h > > >

Re: [Nouveau] [PATCH 1/5] PCI: Recognize Thunderbolt devices

On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote: > Detect on probe whether a PCI device is part of a Thunderbolt controller. > > Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234 > on such devices. Detect presence of this VSEC and cache it in a newly > added

Re: [Nouveau] [PATCH 3/5] drm/nouveau: Don't register Thunderbolt eGPU with vga_switcheroo

On Fri, Feb 24, 2017 at 1:19 PM, Lukas Wunner wrote: > An external Thunderbolt GPU can neither drive the laptop's panel nor be > powered off by the platform, so there's no point in registering it with > vga_switcheroo. > In fact, when the external GPU is runtime suspended, >

Re: [Nouveau] How to check for proper MSI support?

On Thu, Jul 3, 2014 at 10:32 PM, Ilia Mirkin imir...@alum.mit.edu wrote: So let me get this straight -- you're suggesting I add a quirk for every PCI chipset that doesn't support MSI? There are probably hundreds of these... anything made before 1999 or so, and probably a bunch since then too.