Displaying 20 results from an estimated 600 matches similar to: "[PATCH v2 1/9] acpi: Rename v1 DSM to mux to avoid ambiguity"
2015 May 25
15
[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
precising the v1.
Signed-off-by: Pierre Moreau <pierre.morrow at free.fr>
---
drm/nouveau/nouveau_acpi.c | 64 +++++++++++++++++++++++-----------------------
drm/nouveau/nouveau_acpi.h | 4 +--
drm/nouveau/nouveau_drm.c | 4 +--
drm/nouveau/nouveau_vga.c | 10 ++++----
4 files changed, 41 insertions(+), 41
2019 May 07
2
[PATCH 1/5] drm: don't set the pci power state if the pci subsystem handles the ACPI bits
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
2016 Jul 07
6
[PATCH v2 0/4] nouveau RPM fixes for Optimus
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).
2016 May 24
7
[PATCH 0/4] nouveau fixes for RPM/Optimus-related hangs
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
2015 May 25
2
[PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally
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.
2019 May 04
10
[PATCH 0/5] Potential fix for runpm issues on various laptops
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.
2016 Jul 15
8
[PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
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
2015 May 26
2
[PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally
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
2015 May 28
3
[PATCH v2 8/9] acpi: Add support for Apple Gmux _DMS
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
2014 Mar 26
3
[PATCH] acpi: allow non-optimus setups to load vbios from acpi
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
2016 May 14
1
[PATCH] drm/nouveau: check function before using it
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
2014 Apr 05
2
[PATCH] acpi: allow non-optimus setups to load vbios from acpi
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
2016 May 27
3
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
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
2016 May 25
3
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
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
2016 May 30
2
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
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
2019 May 07
8
[PATCH v2 0/4] Potential fix for runpm issues on various laptops
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
2016 May 30
2
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
+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
> >
2012 Mar 23
3
[PATCH 0/3] Prepare nouveau for other switcheroo handlers
While working on a vga_switcheroo handler for Apple's Macbook Pros I stumbled
upon a few bugs regarding the usage of nouveau with other switcheroo handlers
and module unloading, here are my fixes for them.
Andreas Heider (3):
drm/nouveau: Initialize has_optimus
drm/nouveau: Check dsm on switcheroo unregister
drm/nouveau: Unregister switcheroo client on exit
2014 Mar 22
16
[Bug 76475] New: Nouveau fails to load due to unknown opcode 0x80
https://bugs.freedesktop.org/show_bug.cgi?id=76475
Priority: medium
Bug ID: 76475
Assignee: nouveau at lists.freedesktop.org
Summary: Nouveau fails to load due to unknown opcode 0x80
QA Contact: xorg-team at lists.x.org
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: patrick.clara at
2014 Mar 19
2
[PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm
There was a proliferation of duplicated checks for runpm == -1 &&
optimus. Instead of continuing that tradition, get rid of all of them,
only doing the optimus computation once on load.
This should hopefully fix secondary cards suspending and then being
unable to come back in non-optimus setups.
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
Cc: <stable at