Re: [Nouveau] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 14:09, Rafael J. Wysocki wrote: > > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 10/27/22 11:52, Matthew Garrett wrote: > &g

Re: [Nouveau] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 11:52, Matthew Garrett wrote: > > On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > > > >> The *only* behavior which actually is new in 6.1 is the native GPU > >> drivers now doing the equivalent of: > >>

Re: [Nouveau] [PATCH 1/4] ACPI: OSI: Remove Linux-Dell-Video _OSI string

On Wed, Aug 24, 2022 at 8:28 PM Limonciello, Mario wrote: > > [Public] > > > > > -Original Message- > > From: Kai-Heng Feng > > Sent: Wednesday, August 24, 2022 09:17 > > To: Limonciello, Mario > > Cc: raf...@kernel.org; Len Brown ; > > nouveau@lists.freedesktop.org;

Re: [Nouveau] [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

m the "Other issues" section of > the refactor RFC (resulting in patches 15-29 which are new in v2). > > Please review and test! I hope to be able to make an immutable branch > based on 5.20-rc1 + this series available for merging into the various > touched subsystems once 5.20-

Re: [Nouveau] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members

On Tue, Feb 15, 2022 at 8:24 PM Gustavo A. R. Silva wrote: > > On Tue, Feb 15, 2022 at 09:19:29PM +0200, Leon Romanovsky wrote: > > On Tue, Feb 15, 2022 at 01:21:10PM -0600, Gustavo A. R. Silva wrote: > > > On Tue, Feb 15, 2022 at 10:17:40AM -0800, Kees Cook wrote: > > > > On Tue, Feb 15, 2022 at

[Nouveau] [PATCH v2 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

From: Rafael J. Wysocki The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION() macro and the ACPI handle produced by the former comes from the ACPI device object produced by the latter, so it is way more straightforward to evaluate the latter directly instead of passing the handle

[Nouveau] [PATCH v1 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

From: Rafael J. Wysocki The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION() macro and the ACPI handle produced by the former comes from the ACPI device object produced by the latter, so it is way more straightforward to evaluate the latter directly instead of passing the handle

Re: [Nouveau] [PATCH 000/141] Fix fall-through warnings for Clang

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley wrote: > > On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote: > > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley > > wrote: [cut] > > > > Maintainers routinely review 1-line trivial patches, not to mention > > internal API changes, etc. > >

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

On Mon, Dec 9, 2019 at 12:17 PM Karol Herbst wrote: > > anybody any other ideas? Not yet, but I'm trying to collect some more information. > It seems that both patches don't really fix > the issue and I have no idea left on my side to try out. The only > thing left I could do to further

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

On Fri, Nov 22, 2019 at 12:52 PM Mika Westerberg wrote: > [cut] [I'm really running out of time for today, unfortunately.] > > > > The current design is mostly based on the PCI PM Spec 1.2, so it would > > > > be consequent to follow system-wide suspend in PM-runtime and avoid > > > > putting

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

On Fri, Nov 22, 2019 at 12:34 PM Karol Herbst wrote: > > On Fri, Nov 22, 2019 at 12:30 PM Rafael J. Wysocki wrote: > > [cut] > > > > the issue is not AML related at all as I am able to reproduce this > issue without having to invoke any of that at all, I just

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

On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > > wrote: > > > > > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. W

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

-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.freedesktop.org > Bugzilla: https://

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

On Fri, Nov 22, 2019 at 1:13 AM Karol Herbst wrote: > > so while trying to test with d3cold disabled, I noticed that I run > into the exact same error. Does this mean that you disabled d3cold on the GPU via sysfs (the "d3cold_allowed" attribute was 0) and the original problem still occurred in

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

On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > > wrote: > > > > > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg

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

On Thu, Nov 21, 2019 at 5:06 PM Karol Herbst wrote: > > On Thu, Nov 21, 2019 at 4:47 PM Rafael J. Wysocki wrote: > > > > On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote: > > > > > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg > > > wrote:

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

On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote: > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg > wrote: > > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > wrot

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

On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > wrote:

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

On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg wrote: > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote: > > > last week or so I found systems where the GPU was under the "PCI > > > Express Root Port" (name from lspci) and on those systems a

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

On Thu, Nov 21, 2019 at 12:17 PM Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 12:03:52PM +0100, Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol H

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

On Thu, Nov 21, 2019 at 12:08 PM Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote: > > > > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbs

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

On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg > wrote: > > > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote: > > > with the branch and patch applied: > > > https:/

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

On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg wrote: > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote: > > with the branch and patch applied: > >

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

On Wed, Nov 20, 2019 at 10:40 PM Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 10:37 PM Rafael J. Wysocki wrote: > > > > On Wed, Nov 20, 2019 at 4:53 PM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrot

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

On Wed, Nov 20, 2019 at 4:53 PM Mika Westerberg wrote: > > On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > > > > On Wed, Nov 20, 2019 at 1:09

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

On Wed, Nov 20, 2019 at 1:10 PM Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki wrote: > > > > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote: > > > > > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki > > > wrot

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

On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki wrote: > > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote: > > > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki > > wrote: > > > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg &g

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

On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki wrote: > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > > wrote: > > > > > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. W

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

On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg wrote: > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote: > > On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg > > wrote: > > > > > > Hi Karol, > > > > > > On Tue

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

On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg wrote: > > Hi Karol, > > 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: > > > > > > [+cc Dave] > > > > > > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Karol Herbst wrote: > > >

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

roached. OK, please let me know when the _OSI string in question can be dropped. > On Mon, Oct 21, 2019 at 10:14 AM Rafael J. Wysocki wrote: > > > > On Mon, Oct 21, 2019 at 4:14 AM Alex Hung wrote: > > > > > > We have done some tests on three of Intel + nVidia confi

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Mon, Oct 21, 2019 at 4:14 AM Alex Hung wrote: > > We have done some tests on three of Intel + nVidia configuration > systems with OEM _OSI strings removed - while some bugs are still > observed, ex. one out of three has suspend/resume issues, no system > crashes were observed - the biggest

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

On Tuesday, October 1, 2019 12:00:50 PM CEST Karol Herbst wrote: > On Tue, Oct 1, 2019 at 11:11 AM Mika Westerberg > wrote: > > > > On Tue, Oct 01, 2019 at 10:56:39AM +0200, Karol Herbst wrote: > > > On Tue, Oct 1, 2019 at 10:47 AM Mika Westerberg > > > wrote: > > > > > > > > On Mon, Sep 30,

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

On Tue, Oct 1, 2019 at 9:34 PM Bjorn Helgaas wrote: > > 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

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

Alex Hung and Mario need to answer this question I think. > On Mon, Aug 19, 2019 at 11:52 AM Rafael J. Wysocki wrote: > > > > On Thursday, August 15, 2019 12:47:35 AM CEST Dave Airlie wrote: > > > On Thu, 15 Aug 2019 at 07:31, Karol Herbst wrote: &g

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thursday, August 15, 2019 12:47:35 AM CEST Dave Airlie wrote: > On Thu, 15 Aug 2019 at 07:31, Karol Herbst wrote: > > > > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c. > > > > The original commit message didn't even make sense. AMD _does_ support it > > and > > it works with

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

spect it will also > fix the issue that was worked around in commit 7c53a722459c ("r8169: > don't use MSI-X on RTL8168g"). > > Thomas Martitz reports that this change also solves an issue where > the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive

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

, 12, 15, 0, false); > + /* Force rewriting of prefetch registers to avoid > +* S3 resume issues on Intel PCI bridges that occur when > +* these registers are not explicitly written. > +*/ > + pci_restore

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

On Tuesday, September 11, 2018 5:35:13 AM CEST Daniel Drake wrote: > 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

Re: [Nouveau] [PATCH 1/5] drm/nouveau: Prevent RPM callback recursion in suspend/resume paths

On Wed, Jul 18, 2018 at 10:11 PM, Lyude Paul wrote: > On Wed, 2018-07-18 at 10:36 +0200, Lukas Wunner wrote: >> On Wed, Jul 18, 2018 at 10:25:05AM +0200, Lukas Wunner wrote: >> > The GPU contains an i2c subdevice for each connector with DDC lines. >> > I believe those are modelled as children of

Re: [Nouveau] [PATCH 1/5] drm/nouveau: Prevent RPM callback recursion in suspend/resume paths

On Wed, Jul 18, 2018 at 10:25 AM, Lukas Wunner wrote: > On Wed, Jul 18, 2018 at 09:38:41AM +0200, Rafael J. Wysocki wrote: >> On Tue, Jul 17, 2018 at 8:20 PM, Lukas Wunner wrote: >> > Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire() >> > wants it in r

Re: [Nouveau] [PATCH 1/5] drm/nouveau: Prevent RPM callback recursion in suspend/resume paths

On Tue, Jul 17, 2018 at 8:34 PM, Lyude Paul wrote: > On Tue, 2018-07-17 at 20:32 +0200, Lukas Wunner wrote: >> On Tue, Jul 17, 2018 at 02:24:31PM -0400, Lyude Paul wrote: >> > On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote: >> > > Okay, the PCI device is suspending and the

Re: [Nouveau] [PATCH 1/5] drm/nouveau: Prevent RPM callback recursion in suspend/resume paths

On Tue, Jul 17, 2018 at 8:20 PM, Lukas Wunner wrote: > On Tue, Jul 17, 2018 at 12:53:11PM -0400, Lyude Paul wrote: >> On Tue, 2018-07-17 at 09:16 +0200, Lukas Wunner wrote: >> > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: >> > > In order to fix all of the spots that need to have

Re: [Nouveau] [PATCH 1/5] drm/nouveau: Prevent RPM callback recursion in suspend/resume paths

On Tue, Jul 17, 2018 at 9:16 AM, Lukas Wunner wrote: > [cc += linux-pm] > > Hi Lyude, > > First of all, thanks a lot for looking into this. > > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: >> In order to fix all of the spots that need to have runtime PM get/puts() >> added, we need

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

On Wednesday, February 21, 2018 10:57:14 AM CET Rafael J. Wysocki wrote: > On Tue, Feb 20, 2018 at 10:29 PM, Bjorn Helgaas <helg...@kernel.org> wrote: > > On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote: > >> PCI devices not bound to a driver are suppo

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

ne for unbound devices. That is a fair point, but if you look at pci_pm_runtime_suspend(), it doesn't actually save anything for devices without drivers, so we'd just restore the original initial state for them every time. If we are to restore the entire state on runtime resume, pci_pm_runtime_suspend(

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

ove-mentioned use cases. Other use > cases might require a full-blown pci_save_state() / pci_restore_state() > or execution of fixups. We can add that once use cases materialize, > let's not inflate the code unnecessarily. > > Cc: Bjorn Helgaas <bhelg...@google.com> > Cc: Rafael J

Re: [Nouveau] [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote: > There are ~4300 uses of pr_warn and ~250 uses of the older > pr_warning in the kernel source tree. > > Make the use of pr_warn consistent across all kernel files. > > This excludes all files in tools/ as there is a separate >

Re: [Nouveau] [PATCH] acpi: video: Move ACPI_VIDEO_NOTIFY_* defines to acpi/video.h

On Wednesday, November 09, 2016 06:15:56 PM Hans de Goede wrote: > acpi_video.c passed the ACPI_VIDEO_NOTIFY_* defines as type code to > acpi_notifier_call_chain(). Move these defines to acpi/video.h so > that acpi_notifier listeners can check the type code using these > defines. > >