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

On Thu, Jul 11, 2019 at 6:47 AM Bjorn Helgaas wrote: > I applied this (slightly revised as below) to pci/misc and I think we > can still squeeze it in for v5.3. Thanks. Tested briefly and it seems to be working fine! ___ Nouveau mailing list

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

for the majority of affected users. This commit takes inspiration from an earlier patch by Daniel Drake. Link: https://devtalk.nvidia.com/default/topic/1024022 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75985 Cc: Aaron Plattner Cc: Peter Wu Cc: Ilia Mirkin Cc: Karol Herbst Cc: Maik Freudenberg

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

On Fri, Jun 14, 2019 at 4:03 AM Bjorn Helgaas wrote: > Is it possible that this works on Windows but not Linux because they > handle ACPI hotplug slightly differently? > > Martin did some nice debug [1] and found that _DSM, _PS0, and _PS3 > functions write the config bit at 0x488. The dmesg log

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

like this quirk should fix audio support for the majority of affected users. This commit takes inspiration from an earlier patch by Daniel Drake. Link: https://devtalk.nvidia.com/default/topic/1024022 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75985 Cc: Aaron Plattner Cc: Peter Wu Cc

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

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 kernel. That's weird, I would not expect a behaviour change in the latest patch. pci_restore_config_dword() has some debug messages,

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

u G5 is unresponsive after S3 suspend/resume. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069 Signed-off-by: Daniel Drake --- drivers/pci/pci.c | 25 + 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 29ff96

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

On Wed, Sep 12, 2018 at 5:05 PM, Rafael J. Wysocki wrote: > Passing the extra bool around is somewhat clumsy, but I haven't found > a cleaner way to do it, so Thanks, according to your suggestion (which I plan to follow after this) we will remove this parameter for v4.20+ and have all the

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

nresponsive after S3 suspend/resume. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069 Signed-off-by: Daniel Drake --- Notes: Replaces patch: PCI: add prefetch quirk to work around Asus/Nvidia suspend issues Some of the more verbose info was moved to bugzilla: https:/

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

I have created https://bugzilla.kernel.org/show_bug.cgi?id=201069 to archive the research done so far. On Fri, Sep 7, 2018 at 11:05 PM, Peter Wu wrote: > Windows 10 unconditionally rewrites these registers (BAR, I/O Base + > Limit, Memory Base + Limit, etc. from top to bottom), see annotations:

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

On Fri, Sep 7, 2018 at 2:40 PM, Sinan Kaya wrote: > On 9/6/2018 10:36 PM, Daniel Drake wrote: >> >> + if (pci_dev->class == PCI_CLASS_BRIDGE_PCI << 8) >> + pci_setup_bridge_mmio_pref(pci_dev); > > > This should probably some kind of a qui

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

ehaviour, which also rewrites these registers during S3 resume (checked with qemu tracing). Link: https://marc.info/?i=CAD8Lp46Y2eOR7WE28xToUL8s-aYiqPa0nS=1gsd0axkddxq...@mail.gmail.com Link: https://bugs.freedesktop.org/show_bug.cgi?id=105760 Signed-off-by: Daniel Drake --- Notes: Replaces pa

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

On Sat, Sep 1, 2018 at 3:12 AM, Bjorn Helgaas wrote: > Can we tell whether Windows rewrites this register unconditionally at > resume-time? If so, it may be more robust for Linux to do the same. > The whole thing is black magic, which I hate, but if it's our only > choice, it may be better to

Re: [Nouveau] Rewriting Intel PCI bridge prefetch base address bits solves nvidia graphics issues

On Tue, Aug 28, 2018 at 5:57 PM, Peter Wu wrote: > Only non-bridge devices can be passed to a guest, but perhaps logging > access to the emulated bridge is already sufficient. The Prefetchable > Base Upper 32 Bits register is at offset 0x28. > > In a trace where the Nvidia device is

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

On Tue, Sep 4, 2018 at 2:43 PM, Mika Westerberg wrote: > Yes, can you check if the failing device BAR is included in any of the > above entries? If not then it is probably not related. mtrr again for reference: reg00: base=0x0c000 ( 3072MB), size= 1024MB, count=1: uncachable reg01:

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

On Mon, Sep 3, 2018 at 8:12 PM, Mika Westerberg wrote: > We have seen one similar issue with LPSS devices when BIOS assigns > device BARs above 4G (which is not the case here) and it turned out to > be misconfigured MTRR register or something like that. It may not be > related at all but it could

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

On Sat, Sep 1, 2018 at 3:12 AM, Bjorn Helgaas wrote: > If true, this sounds like some sort of erratum, so it would be good to > get some input from Intel, and I cc'd a few Intel folks. Yes, it would be great to get their input. > It's interesting that all the systems below are from Asus. That

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

it to only running on Asus products. This fix was tested on all the affected models that we have in hands (X542UQ, UX533FD, X530UN, V272UN). Signed-off-by: Daniel Drake --- Notes: If anyone has ideas for why writing this register makes a difference, or suggestions for other approaches

Re: [Nouveau] Rewriting Intel PCI bridge prefetch base address bits solves nvidia graphics issues

On Thu, Aug 30, 2018 at 5:40 PM, Peter Wu wrote: > As the BIOS date is not visible, can you also confirm that this message > is visible in dmesg? > >nouveau: detected PR support, will not use DSM Yes, that gets logged. > For laptops, it appears that you have to do at least two things: > -

Re: [Nouveau] Rewriting Intel PCI bridge prefetch base address bits solves nvidia graphics issues

On Tue, Aug 28, 2018 at 5:57 PM, Peter Wu wrote: > Just to be sure, after "sleep", do both devices report "suspended" in > /sys/bus/pci/devices/:00:1c.0/power/runtime_status > /sys/bus/pci/devices/:01:00.0/power/runtime_status > > and was this reproduced with a recent mainline kernel with

Re: [Nouveau] Rewriting Intel PCI bridge prefetch base address bits solves nvidia graphics issues

On Fri, Aug 24, 2018 at 11:42 PM, Peter Wu wrote: > Are these systems also affected through runtime power management? For > example: > > modprobe nouveau# should enable runtime PM > sleep 6 # wait for runtime suspend to kick in > lspci -s1: # runtime resume by

[Nouveau] Rewriting Intel PCI bridge prefetch base address bits solves nvidia graphics issues

Hi, We are facing a suspend/resume problem with many different Asus laptop models (30+ products) with Intel chipsets (multiple generations) and nvidia GPUs (several different ones). Reproducers include: 1. Boot 2. Suspend/resume 3. Load nouveau driver 4. Start X 5. Observe slow X startup and

Re: [Nouveau] Kernel panic on nouveau during boot on NVIDIA NV118 (GM108)

On Fri, Jun 2, 2017 at 4:01 AM, Chris Chiu wrote: > We are working with new desktop that have the NVIDIA NV118 > chipset. > > During boot, the display becomes unusable at the point where the > nouveau driver loads. We have reproduced on 4.8, 4.11 and linux > master (4.12-rc3).

[Nouveau] [PATCH] drm/nouveau/core: recognise GP107 chipset

this is working fine. Signed-off-by: Chris Chiu <c...@endlessm.com> Signed-off-by: Daniel Drake <dr...@endlessm.com> --- drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 29 +++ 1 file changed, 29 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/