On Mon, Dec 24, 2018 at 03:52:55PM +0100, Noralf Trønnes wrote:
>
>
> Den 24.12.2018 00.10, skrev Peter Wu:
> > On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote:
> > >
> > >
> > > Den 23.12.2018 01.55, skrev Peter Wu:
>
On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote:
>
>
> Den 23.12.2018 01.55, skrev Peter Wu:
> > After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
> > "dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
)
drm_framebuffer_remove(fb_helper->fb); // yay!
}
Due to calling "drm_fb_helper_fini" however, "dev->fb_helper" will be NULL and
thus this function does nothing on the error path.
So in summary, "drm_fb_helper_fbdev_setup" calls the driver callb
/0x40
This can be reproduced with QEMU and CONFIG_FB_LITTLE_ENDIAN=n.
Link: https://lkml.kernel.org/r/20181221083226.GI23332@shao2-debian
Link: https://lkml.kernel.org/r/20181223004315.GA11455@al
Fixes: 8741216396b2 ("drm/fb-helper: Add drm_fb_helper_fbdev_setup/teardown()")
Reported-by: kernel te
On Mon, Oct 01, 2018 at 01:13:59PM -0700, Fubo Chen wrote:
> On Tue, Sep 4, 2018 at 2:10 PM Peter Wu wrote:
> >
> > "crtc->helper_private" is not initialized by the QXL driver and thus the
> > "crtc_funcs->disable" call would crash (resulting in s
ot* regressed (i.e. it still trips on a
use-after-free in qxl_check_idle via qxl_ttm_fini).
Ideally setup/teardown is replaced by drm_fbdev_generic_setup as that
would result in further code reduction, improve error handling (like not
leaking shadow memory), but unfortunately QXL has no implem
The "initialized" member is going away. suspend/resume still works (even
if bochsfb_create is forced to fail).
Signed-off-by: Peter Wu
---
drivers/gpu/drm/bochs/bochs_drv.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bochs/boch
Clarify the relation between drm_fb_helper_fbdev_setup/teardown. Clarify
requirements for the new generic fbdev emulation API and log some more
details in case the driver does something wrong. Fix related typos.
Cc: Noralf Trønnes
Signed-off-by: Peter Wu
---
drivers/gpu/drm/drm_fb_helper.c
The drm_get_pci_dev API is deprecated, replace it by drm_dev_register.
Signed-off-by: Peter Wu
---
drivers/gpu/drm/bochs/bochs.h | 2 +-
drivers/gpu/drm/bochs/bochs_drv.c | 34 +--
drivers/gpu/drm/bochs/bochs_hw.c | 2 +-
3 files changed, 30 insertions(+), 8
> /sys/class/vtconsole/vtcon1/bind; rmmod bochs_drm'
and also with Xorg + fbdev (startx -> xterm). The latter triggered a
warning in ttm_bo_vm_open that existed before, see
https://lkml.kernel.org/r/1464000533-13140-4-git-send-email-msta...@suse.de
Acked-by: Daniel Vetter
Signed-off-by
s_drm
echo 0 > /sys/class/vtconsole/vtcon1/bind
rtcwake -s 1 -m mem
# 2. s/r in normal sitation
echo 1 > /sys/class/vtconsole/vtcon1/bind
rtcwake -s 1 -m mem
# 3. unload module (and s/r for good measure)
echo 0 > /sys/class/vtconsole/vtcon1/bind
rmmo
On Wed, Sep 05, 2018 at 04:46:29PM +0200, Daniel Vetter wrote:
> On Wed, Sep 05, 2018 at 04:41:27PM +0200, Peter Wu wrote:
> > Currently unloading bochs_drm (after unbinding the vtconsole) results in
> > a warning about a leaked connector:
> >
> > [drm:drm_
> /sys/class/vtconsole/vtcon1/bind; rmmod bochs_drm'
and also with Xorg + fbdev (startx -> xterm). The latter triggered a
warning in ttm_bo_vm_open that existed before, see
https://lkml.kernel.org/r/1464000533-13140-4-git-send-email-msta...@suse.de
Signed-off-by: Peter Wu
---
drivers/
el_validate_surface:
failed on 0
This seems to be triggered by QXL_IO_NOTIFY_CMD after
QXL_IO_DESTROY_PRIMARY_ASYNC, but aside from the warning things still
seem to work (tested with both the GTK and -spice options).
Signed-off-by: Peter Wu
---
Hi,
I found this issue while trying to suspend a VM t
dio function (see also nouveau
bug https://bugs.freedesktop.org/show_bug.cgi?id=75985) so most of the
above issues should not occur.
Hope it helps, and if desired you can add:
Tested-by: Peter Wu
For the following patches, you can also add my Reviewed-by:
vga_switcheroo: Update PCI current
entation on these methods somewhere?
The ACPI interface is documented in
drivers/gpu/drm/amd/include/amd_acpi.h while
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c contains some glue for
ACPI and the amdgpu driver (similar code exists for radeon).
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
u/drm/nouveau/nouveau_drv.h
> @@ -37,6 +37,8 @@
> * - implemented limited ABI16/NVIF interop
> */
>
> +#include
> +
> #include
> #include
> #include
> @@ -161,6 +163,10 @@ struct nouveau_drm {
> struct nvbios vbios;
> struct nouveau_display *display;
> struct backlight_device *backlight;
> +#ifdef CONFIG_ACPI
> + struct notifier_block acpi_nb;
> + struct work_struct acpi_work;
> +#endif
>
> /* power management */
> struct nouveau_hwmon *hwmon;
> --
> 2.9.3
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
--
Kind regards,
Peter Wu
https://lekensteyn.nl
> Signed-off-by: Hans de Goede
Reviewed-by: Peter Wu
> ---
> drivers/acpi/acpi_video.c | 11 ---
> include/acpi/video.h | 11 +++
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_vid
On Wed, Nov 02, 2016 at 11:47:03AM +, Emil Velikov wrote:
> On 2 November 2016 at 11:14, Peter Wu wrote:
> > On Tue, Nov 01, 2016 at 06:13:34PM +, Emil Velikov wrote:
> >> sysfs file wakes up the device. The latter of which may
> >> be slow and i
Emil Velikov
See below for one observation. Other than that, strace confirms that
the new sysfs files are being accessed.
Reviewed-and-tested-by: Peter Wu
This was tested with Linux 4.8.4 (unpatched) and libdrm 2.4.71 (+this
patch) with i915 + nouveau. Tested with running glxgears and
On Tue, Nov 01, 2016 at 09:24:23AM -0400, Alex Deucher wrote:
> On Tue, Nov 1, 2016 at 12:55 AM, Dave Airlie wrote:
> > On 1 November 2016 at 08:48, Peter Wu wrote:
> >> Check whether the kernel really supports power resources for a device,
> >> otherwise the power mi
esktop.org/show_bug.cgi?id=98398
Reported-and-tested-by: Rick Kerkhof
Reviewed-by: Mika Westerberg
Signed-off-by: Peter Wu
---
v2: collected tags from Rick and Mika; added ACPICA note as requested by Mika
I suggest Cc: stable (if the maintainer is OK with that?)
---
drivers/gpu/drm/nouveau/nouveau_
uveau/acpi: fix lockup with PCIe runtime PM")
Signed-off-by: Peter Wu
---
Hi,
Maybe Cc: stable (4.8+)?
Compile-tested only. Rick, can you test if this patch fixes the problem for you?
This check was actually in the original patch, but it was changed:
https://lists.freedesktop.org/archiv
On Wed, Aug 31, 2016 at 02:21:31PM +0200, Roland Singer wrote:
> Am 31.08.2016 um 13:46 schrieb Peter Wu:
> > On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote:
> >> Am 30.08.2016 um 21:53 schrieb Peter Wu:
> >>> On Mon, Aug 29, 2016 at 11:02:1
On Wed, Aug 31, 2016 at 01:27:36PM +0200, Roland Singer wrote:
> Am 30.08.2016 um 21:53 schrieb Peter Wu:
> > On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
> >> [+cc linux-acpi, linux-kernel, dri-devel]
> >>
> >> Hi Roland,
> >>
> &
On Mon, Aug 29, 2016 at 11:02:10AM -0500, Bjorn Helgaas wrote:
> [+cc linux-acpi, linux-kernel, dri-devel]
>
> Hi Roland,
>
> I have no idea how to debug this problem. Are you seeing something
> that suggests it may be a PCI problem?
Yes I suspect there is an ACPI and/ or PCI problem, possibly
d stuff.)
I understood that Roland's intent is to check the power state, not use
the suspend functionality of bbswitch, if you load bbswitch without
module options amd do not write to /proc/bbswitch, then it allows you to
read out the actual status (you could also just use lspci -H1 for that
though).
--
Kind regards,
Peter Wu
https://lekensteyn.nl
before checking bridge_d3
(in case the user changed d3cold_allowed), but that is such an unlikely
case and likely fragile anyway. The current patch is suggested by Mika
in http://www.spinics.net/lists/linux-pci/msg52599.html
Cc: Mika Westerberg
Signed-off-by: Peter Wu
---
Hi,
This idea is floating
On Fri, Jul 29, 2016 at 03:45:50PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Peter Wu [mailto:peter at lekensteyn.nl]
> > Sent: Thursday, July 28, 2016 8:00 PM
> > To: Lukas Wunner
> > Cc: Deucher, Alexander; dri-devel at lists.f
On Thu, Jul 28, 2016 at 05:40:31PM +0200, Lukas Wunner wrote:
> On Thu, Jul 28, 2016 at 03:33:25PM +, Deucher, Alexander wrote:
> > > From: Peter Wu [mailto:peter at lekensteyn.nl]
> > > Sent: Thursday, July 21, 2016 6:43 AM
> > > In case you missed it, Dave'
, Jul 15, 2016 at 03:12:14PM +0200, Peter Wu wrote:
> 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 patche
ists.freedesktop.org/archives/dri-devel/2016-July/112759.html
--
Kind regards,
Peter Wu
https://lekensteyn.nl
On Fri, Jul 15, 2016 at 06:54:27PM +0200, Peter Wu wrote:
> On Fri, Jul 15, 2016 at 12:41:49PM -0400, Ilia Mirkin wrote:
> > On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu wrote:
> > > On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote:
> > >> On Fri, Jul 15, 20
On Fri, Jul 15, 2016 at 12:41:49PM -0400, Ilia Mirkin wrote:
> On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu wrote:
> > On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote:
> >> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu wrote:
> >> > Hi,
> >> >
&
On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote:
> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu wrote:
> > Hi,
> >
> > Here are two patches to fix an issue reported on kernel bugzilla (infinite
> > loop
> > due to unchecked function) and a more imp
y for _PR3. Added affected machines.
v3: fixed block comment coding style.
Reviewed-by: Mika Westerberg
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 35 ++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/d
ned-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 572ac30..ad273ad 100644
--- a/drivers/gpu/drm/nouveau/nouv
Return the set of supported functions to the caller. No functional
changes.
Reviewed-by: Hans de Goede
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
implicit assumption more obvious.
Convert int to bool and rename has_dsm to has_mux while at it. Let the
caller set nouveau_dsm_priv.dhandle as needed.
v2: pass dhandle to the caller.
Reviewed-by: Hans de Goede
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 58
tps://lists.freedesktop.org/archives/dri-devel/2016-July/112759.html
Peter Wu (4):
drm/nouveau/acpi: ensure matching ACPI handle and supported functions
drm/nouveau/acpi: return supported DSM functions
drm/nouveau/acpi: check for function 0x1B before using it
drm/nouveau/acpi: fix lockup with P
On Wed, Jul 13, 2016 at 06:17:47PM +0100, Chris Wilson wrote:
> On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called
> > while nouveau was runtime suspended, a deadlock would occur due to
> > nouv
On Wed, Jul 13, 2016 at 04:57:19PM +0200, Daniel Vetter wrote:
> On Wed, Jul 13, 2016 at 02:40:50PM +0200, Peter Wu wrote:
> > On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote:
> > > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > > > The F
f reviewed or whatever. Since the "device links" series
> hasn't landed yet, it's still possible I think to ask for feature
> requests should it not work for this particular use case. The
> linux-pm at vger.kernel.org mailing list is the right place to inquire
> about the series.
>
> Thanks for raising this important question.
I'll give this a go after finishing the PR3 nouveau patches and fixing
some locking issues.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote:
> On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called
> > while nouveau was runtime suspended, a deadlock wou
On Tue, Jul 12, 2016 at 09:16:22PM +0200, Lukas Wunner wrote:
> On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called
> > while nouveau was runtime suspended, a deadlock would occur due to
> > nouv
done for performance reasons though).
Cc: Chris Wilson
Cc: Daniel Vetter
Signed-off-by: Peter Wu
---
Tested on top of v4.7-rc5, the deadlock is gone.
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +--
drivers/gpu/drm/nouveau/nouveau_drv.h | 1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 54
y for _PR3. Added affected machines.
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index ad273a
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
---
d
Return the set of supported functions to the caller. No functional
changes.
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau
implicit assumption more obvious.
Convert int to bool and rename has_dsm to has_mux while at it. Let the
caller set nouveau_dsm_priv.dhandle as needed.
v2: pass dhandle to the caller.
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 58 +++---
1
ty of pci_bridge_d3_possible(). I'll send a
separate mail for this to linux-pci.
Kind regards,
Peter
[1]: https://lists.freedesktop.org/archives/nouveau/2016-May/025116.html
[2]: https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/?h=pci/pm
Peter Wu (4):
drm/nouveau/acpi: ensure matching A
On Wed, Jun 01, 2016 at 12:28:47PM +0300, Mika Westerberg wrote:
> On Tue, May 31, 2016 at 01:02:31PM +0200, Peter Wu wrote:
> > On Tue, May 31, 2016 at 11:43:56AM +0300, Mika Westerberg wrote:
> > > On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote:
> > > > D
On Tue, May 31, 2016 at 02:20:26PM +0200, Lukas Wunner wrote:
> On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote:
> > Do you have any suggestions for the case where the pcieport driver
> > refuses to put the bridge in D3 (because the BIOS is too old)? In that
> > ca
On Tue, May 31, 2016 at 01:34:43PM +0200, Lukas Wunner wrote:
> On Mon, May 30, 2016 at 07:03:46PM +0200, Peter Wu wrote:
> > On Sun, May 29, 2016 at 05:50:06PM +0200, Lukas Wunner wrote:
> > > How exactly did you reach the situation where the root port didn't wake
> >
On Tue, May 31, 2016 at 11:43:56AM +0300, Mika Westerberg wrote:
> On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote:
> > Do you have any suggestions for the case where the pcieport driver
> > refuses to put the bridge in D3 (because the BIOS is too old)? In that
> > ca
On Sun, May 29, 2016 at 05:50:06PM +0200, Lukas Wunner wrote:
> Hi Peter,
>
> On Fri, May 27, 2016 at 03:07:33AM +0200, Peter Wu wrote:
> > On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> > > nouveau_drm_load() calls pm_runtime_put() if nouveau_ru
e called even
> > though the runtime PM on the PCIe port does nothing.
>
> Somehow it does not feel right to poke parent device's fields directly.
>
> What if you just check if it has the method like:
>
> bool no_dsm = acpi_has_method(parent_adev->handle, "_PR3");
>
> That should follow what Windows is doing.
Checking for _PR3 was the intention, but it seems that the ACPI core
does not really store it somewhere. Your check should be simple enough,
I'll use that in the next version.
Do you have any suggestions for the case where the pcieport driver
refuses to put the bridge in D3 (because the BIOS is too old)? In that
case the nouveau driver needs to fallback to the DSM method (but not
when runtime PM is deliberately disabled by writing control=on).
--
Kind regards,
Peter Wu
https://lekensteyn.nl
On Mon, May 30, 2016 at 12:57:09PM +0300, Mika Westerberg wrote:
> +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:
On Mon, May 30, 2016 at 11:48:34AM +0100, Emil Velikov wrote:
> On 27 May 2016 at 22:31, Peter Wu 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 wrote:
> >> > S
On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote:
> Hi Peter,
>
> On 24 May 2016 at 23:53, 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
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.
> + }
> +
> nouveau_fbcon_fini(dev);
> nouveau_accel_fini(drm);
> nouveau_hwmon_fini(dev);
> --
> 2.8.1
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
--
Kind regards,
Peter Wu
https://lekensteyn.nl
nd newer[1] (as observed via an AMLi
debugger trace) and stop using the DSM functions for D3cold when power
resources are available on the parent PCIe port.
[1]:
https://msdn.microsoft.com/windows/hardware/drivers/bringup/firmware-requirements-for-d3cold
Signed-off-by: Peter Wu
---
drive
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
---
d
Return the set of supported functions to the caller. No functional
changes.
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau
implicit assumption more obvious.
Convert int to bool and rename has_dsm to has_mux while at it.
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 55 ++
1 file changed, 23 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
spci -nn >/dev/null; systemctl suspend
Kind regards,
Peter
[1]: https://lkml.kernel.org/r/20160524211309.GH1789 at lahna.fi.intel.com
Peter Wu (4):
drm/nouveau/acpi: ensure matching ACPI handle and supported functions
drm/nouveau/acpi: return supported DSM functions
drm/nouveau/a
//uefi.org/specifications.)
The first parameter for CreateField is evaluated as buffer (sec 19.6.21).
According to 19.3.5.6 (Data Types and Type Conversions) an implicit
conversion to a Buffer is only possible from an Integer and String, a
Package does not belong to the possibilities.
Note that the return value may be an integer for unsupported revision
IDs or UUIDs (like 0x8002). These should be compatible with Buffers
though as stated above and acpi_check_dsm() can handle that case, but
unfortunately sets a Package as fourth argument and can therefore not be
used in nouveau.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
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
---
On Tuesday 23 September 2014 03:52:48 C Bergstr?m wrote:
> Here's where I originally found it
> https://github.com/Bumblebee-Project/Bumblebee/issues/159
> (Adding Peter to cc chain)
>
> I guess there's already a bug id and some (snarky?) comments
> https://bugzilla.kernel.org/show_bug.cgi?id=6364
Hi,
While trying PRIME, I got a lockdep warning after exiting glxgears. Is
it harmful? The command was:
DRI_PRIME=1 glxgears
Offload provider is a GT425M (NVC0), output sink is an Intel i5-460M.
Kind regards,
Peter
dmesg:
=
[ INFO: possible recur
On Friday 02 August 2013 15:58:38 Dave Airlie wrote:
> On Fri, Aug 2, 2013 at 12:41 AM, Peter Wu wrote:
> > Observe that nouveau_optimus_dsm and nouveau_dsm are equal except for
> > the parameters handling (UUID, revision ID and function arguments). The
> > function arguments
On Friday 02 August 2013 15:58:38 Dave Airlie wrote:
> On Fri, Aug 2, 2013 at 12:41 AM, Peter Wu wrote:
> > Observe that nouveau_optimus_dsm and nouveau_dsm are equal except for
> > the parameters handling (UUID, revision ID and function arguments). The
> > function arguments
Hi Dave,
I don't know anything of PM domains, but there was one minor thing I wanted to
mention, see below.
On Monday 29 July 2013 16:06:56 Dave Airlie wrote:
> From: Dave Airlie
Something went wrong here I guess?
> [..]
>
> +static int vga_switcheroo_runtime_resume_hdmi_audio(struct device *
.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
[Integer], ACPI requires [Package] (20130517/nsarguments-95)
As the Intel _DSM method seems to ignore this parameter, let's comply to
the ACPI spec and use a Package instead.
Signed-off-by: Peter Wu
---
What is this code useful for? It
guments-95)
ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
[Buffer], ACPI requires [Package] (20130517/nsarguments-95)
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 67 ++
1 file changed, 20 insertions(+), 47
Hi Dave,
I don't know anything of PM domains, but there was one minor thing I wanted to
mention, see below.
On Monday 29 July 2013 16:06:56 Dave Airlie wrote:
> From: Dave Airlie
Something went wrong here I guess?
> [..]
>
> +static int vga_switcheroo_runtime_resume_hdmi_audio(struct device *
.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
[Integer], ACPI requires [Package] (20130517/nsarguments-95)
As the Intel _DSM method seems to ignore this parameter, let's comply to
the ACPI spec and use a Package instead.
Signed-off-by: Peter Wu
---
What is this code useful for? It
guments-95)
ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
[Buffer], ACPI requires [Package] (20130517/nsarguments-95)
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 67 ++
1 file changed, 20 insertions(+), 47
Hi Dave,
> +int nouveau_dynamic_power_set_state(struct drm_device *dev, int state)
> +{
> + struct nouveau_drm *drm = nouveau_drm(dev);
> + pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
> +
> + if (state == DRM_SWITCH_POWER_DYNAMIC_OFF) {
> + dev->switch_power_state = D
Hi Dave,
> +int nouveau_dynamic_power_set_state(struct drm_device *dev, int state)
> +{
> + struct nouveau_drm *drm = nouveau_drm(dev);
> + pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
> +
> + if (state == DRM_SWITCH_POWER_DYNAMIC_OFF) {
> + dev->switch_power_state = D
81 matches
Mail list logo
