search for: pci_restore_config_dword

...1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 29ff9619b5fa..5d58220b6997 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1289,12 +1289,12 @@ int pci_save_state(struct pci_dev *dev) EXPORT_SYMBOL(pci_save_state); static void pci_restore_config_dword(struct pci_dev *pdev, int offset, - u32 saved_val, int retry) + u32 saved_val, int retry, bool force) { u32 val; pci_read_config_dword(pdev, offset, &val); - if (val == saved_val) + if (!force && val == saved_val) return; for (;;) { @@ -1313,25 +1313,34 @@...

...file changed, 21 insertions(+), 10 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 29ff9619b5fa..e1704100e72d 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1289,13 +1289,15 @@ int pci_save_state(struct pci_dev *dev) EXPORT_SYMBOL(pci_save_state); static void pci_restore_config_dword(struct pci_dev *pdev, int offset, - u32 saved_val, int retry) + u32 saved_val, int retry, bool force) { u32 val; - pci_read_config_dword(pdev, offset, &val); - if (val == saved_val) - return; + if (!force) { + pci_read_config_dword(pdev, offset, &val); + if (val == s...

.../pci/pci.c b/drivers/pci/pci.c > > index 29ff9619b5fa..5d58220b6997 100644 > > --- a/drivers/pci/pci.c > > +++ b/drivers/pci/pci.c > > @@ -1289,12 +1289,12 @@ int pci_save_state(struct pci_dev *dev) > > EXPORT_SYMBOL(pci_save_state); > > > > static void pci_restore_config_dword(struct pci_dev *pdev, int offset, > > - u32 saved_val, int retry) > > + u32 saved_val, int retry, bool force) > > { > > u32 val; > > > > pci_read_config_dword(pdev, offset, &val); > > - if (val == saved_val) > > + if (!force...

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 us of the PCI device address of the parent bridge (lspci -vt) Thanks Daniel

...ons(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 29ff9619b5fa..5d58220b6997 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -1289,12 +1289,12 @@ int pci_save_state(struct pci_dev *dev) > EXPORT_SYMBOL(pci_save_state); > > static void pci_restore_config_dword(struct pci_dev *pdev, int offset, > - u32 saved_val, int retry) > + u32 saved_val, int retry, bool force) > { > u32 val; > > pci_read_config_dword(pdev, offset, &val); > - if (val =...

...(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 29ff9619b5fa..5d58220b6997 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -1289,12 +1289,12 @@ int pci_save_state(struct pci_dev *dev) > EXPORT_SYMBOL(pci_save_state); > > static void pci_restore_config_dword(struct pci_dev *pdev, int offset, > - u32 saved_val, int retry) > + u32 saved_val, int retry, bool force) > { > u32 val; > > pci_read_config_dword(pdev, offset, &val); > - if (val == saved_val) > + if (!force && val == saved_val) > re...

...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 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...

...ons(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 29ff9619b5fa..e1704100e72d 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -1289,13 +1289,15 @@ int pci_save_state(struct pci_dev *dev) > EXPORT_SYMBOL(pci_save_state); > > static void pci_restore_config_dword(struct pci_dev *pdev, int offset, > - u32 saved_val, int retry) > + u32 saved_val, int retry, bool force) > { > u32 val; > > - pci_read_config_dword(pdev, offset, &val); > - if (val =...

.../pci.c >>> index 29ff9619b5fa..5d58220b6997 100644 >>> --- a/drivers/pci/pci.c >>> +++ b/drivers/pci/pci.c >>> @@ -1289,12 +1289,12 @@ int pci_save_state(struct pci_dev *dev) >>> EXPORT_SYMBOL(pci_save_state); >>> >>> static void pci_restore_config_dword(struct pci_dev *pdev, int offset, >>> - u32 saved_val, int retry) >>> + u32 saved_val, int retry, bool force) >>> { >>> u32 val; >>> >>> pci_read_config_dword(pdev, offset, &val); >>> - if (val == saved_va...

...on that works backwards from the > end of the PCI config space to the beginning, see > pci_restore_config_space. Do you have a dmesg where you see the > "restoring config space at offset" messages? > > Would it be reasonable to unconditionally write these registers in > pci_restore_config_dword, like Windows does? That sounds reasonable to me. We did write them unconditionally, prior to 04d9c1a1100b ("[PATCH] PCI: Improve PCI config space writeback") [1]. That commit apparently fixed suspend on some laptop. But at that time, we restored the config space in order of dword 0,...

...ic "restore" operation that works backwards from the end of the PCI config space to the beginning, see pci_restore_config_space. Do you have a dmesg where you see the "restoring config space at offset" messages? Would it be reasonable to unconditionally write these registers in pci_restore_config_dword, like Windows does? Kind regards, Peter

...un, 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 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)...

...itz <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 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://bugzill...

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: fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04 [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown] DRM: failed to idle channel 0 [DRM]