similar to: [PATCH 1/8] acpi: Rename v1 DSM to mux to avoid ambiguity

This is especially true when variables or functions are just called dsm without specifying the v1. Changes since v1: * Fix typo in commit explanation * Change has_dsm to has_mux in nouveau_dsm_detect Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 72 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +--

On Sat, 2019-05-04 at 18:32 +0200, Karol Herbst wrote: > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/nouveau_acpi.c | 6 +++--- > drm/nouveau/nouveau_acpi.h | 4 ++-- > drm/nouveau/nouveau_drm.c | 15 +++++++++++---- > drm/nouveau/nouveau_drv.h | 2 ++ > 4 files changed, 18 insertions(+), 9 deletions(-) > > diff --git

Hi, Here are two patches to fix an issue reported on kernel bugzilla (infinite loop due to unchecked function) and a more important fix to fix hanging Optimus machines when runtime PM is enabled (with pm/pci patches). See the first version[1] for a background on the fixed problems. This is the second revision of incorporating feedback from Emil Velikov (patch 1), Mika Westerberg (patch 4).

Hi, Here are two patches to fix an issue reported on kernel bugzilla (infinite loop due to unchecked function) and a more important fix to fix hanging Optimus machines when runtime PM is enabled (with pm/pci patches). An older (obsolete) patch for the first issue was tested by the reporter: https://bugzilla.kernel.org/show_bug.cgi?id=104791#c11 (it is replaced by "check for function 0x1B

Hi, Here are two patches to fix an issue reported on kernel bugzilla (infinite loop due to unchecked function) and a more important fix to fix hanging Optimus machines when runtime PM is enabled (with pm/pci patches). These are the final patches targeting v4.8. Changes compared to v2[1]: collected R-b from Hans and Mika and fixed a minor comment style issue. I recommend it to be merged before

Do not unconditionally invoke function 0x1B without checking for its availability, it leads to an infinite loop on some firmware. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791 Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)") Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- Hi, I am not sure what exactly 0x1B is used for, it seems related to HDMI

There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin

Hi Peter, On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote: > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > can be runtime-suspended which disables power resources via ACPI. This > is incompatible with DSM, resulting in a GPU device which is still in D3 > and locks up the kernel on resume. > > Mirror the behavior of

On 27 May 2016 at 22:31, Peter Wu <peter at lekensteyn.nl> wrote: > On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote: >> Hi Peter, >> >> On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote: >> > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port >> > can be runtime-suspended which disables

Hi, same for me. The screen does not freeze anymore and the boot succeeds. But now I have this kernel message during boot (for the second card): [ 24.382045] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22 Do you want to have the complete dmesg log? I think this is a new bug. Your patch works for the previous one, so you can close it. Yours, Claas On

While investigating the runpm issues on my GP107 I noticed that something inside devinit makes runpm break. If Nouveau loads up to the point right before doing devinit, runpm works without any issues, if devinit is ran, not anymore. Out of curiousity I even tried to "bisect" devinit by not running it on vbios provided signed PMU image, but on the devinit parser we have inside Nouveau.

On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > can be runtime-suspended which disables power resources via ACPI. This > is incompatible with DSM, resulting in a GPU device which is still in D3 > and locks up the kernel on resume. > > Mirror the behavior of Windows 8 and newer[1] (as

+Rafael On Fri, May 27, 2016 at 01:10:37PM +0200, Peter Wu wrote: > On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote: > > On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > > > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > > > can be runtime-suspended which disables power resources via ACPI. This > >

CCing linux-pci and Bjorn Helgaas. Maybe we could get better insights on how a reasonable fix would look like. Anyway, to me this entire issue looks like something which has to be fixed on a PCI level instead of inside a driver, so it makes sense to ask the pci folks if they have any better suggestions. Original cover letter: While investigating the runpm issues on my GP107 I noticed that

On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau <pierre.morrow at free.fr> wrote: > Most _DSM will return an integer value of 0x80000002 when given an unknown > UUID, revision ID or function ID. Checking locally allows us to differentiate > that case from other ACPI errors, and to not report a "failed to evaluate _DSM" > if 0x80000002 is returned which was confusing.

This patch certainly needs some more work, but I'd like to get some comments. Not sure if it is really related to the gmux or if it is a different Optimus _DSM version. I tested it on my laptop (MCP79/7A + G96) and the G96 successfully goes to sleep, however it is still marked as PWR in vga_switcheroo, despite `vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF)` being called. ---

On Tue, May 26, 2015 at 1:10 AM, Pierre Moreau <pierre.morrow at free.fr> wrote: >> On 26 May 2015, at 00:39, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> >>> On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau <pierre.morrow at free.fr> wrote: >>> Most _DSM will return an integer value of 0x80000002 when given an unknown >>> UUID, revision ID

Hi Dave, ----- Mail original ----- > Changes since v1: [...] > diff --git a/drm/nouveau/nouveau_vga.c b/drm/nouveau/nouveau_vga.c > index 9a6328f..7b13804 100644 > --- a/drm/nouveau/nouveau_vga.c > +++ b/drm/nouveau/nouveau_vga.c > @@ -36,7 +36,7 @@ nouveau_switcheroo_set_state(struct pci_dev *pdev, > { > struct drm_device *dev = pci_get_drvdata(pdev); > > - if

On Mon, Feb 27, 2017 at 05:31:04PM -0800, Joe Perches wrote: > Use a more common logging style. > > Miscellanea: > > o Coalesce formats and realign arguments > o Neaten a few macros now using pr_<level> > > Signed-off-by: Joe Perches <joe at perches.com> I know this is pain, but can you pls split this into: - amd/radeon drivers - drm core (anything

From: Sui Jingfeng <suijingfeng at loongson.cn> 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. Therefore, add the pci_get_base_class() function to suit the need. For example, if an application want to process all PCI(e) display devices in a