entirely and also since we no longer need
to, stop exporting gt215_therm_init
Signed-off-by: Lyude Paul <ly...@redhat.com>
Reviewed-by: Martin Peres <martin.pe...@free.fr>
Lyude Paul (5):
drm/nouveau: Add support for basic clockgating on Kepler1
drm/nouveau: Add support for BLCG on K
Reviewed-by: Lyude Paul <ly...@redhat.com>
On Wed, 2018-02-07 at 18:40 +0100, Thierry Reding wrote:
> From: Thierry Reding <tred...@nvidia.com>
>
> The recently introduced clock gate support breaks on Tegra chips because
> no thermal support is enabled for those devices.
; index 76e237bd989b..6914633037a5 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
>
> void drm_kms_helper_poll_disable(struct drm_device *dev);
> void drm_kms_he
):
Reviewed-by: Lyude Paul <ly...@redhat.com>
On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
>
> DRM drivers poll connectors in 10 sec intervals. The poll worker is
> stopped on
I think your idea of having the extra kerneldoc as a seperate patch to make
this easier to backport should work fine :). Thanks for the good work!
Reviewed-by: Lyude Paul <ly...@redhat.com>
On Wed, 2018-02-14 at 08:41 +0100, Lukas Wunner wrote:
> Introduce a helper to determine if th
au.debug=trace? That should hopefully tell us
> > > more exactly which thing is dying. If you have a cross-compile/distcc
> > > setup handy, a bisect may be even more useful.
> >
> > Erm, sorry, nevermind. You even said it -- nvkm_therm_clkgate_fini is
>
ore their atomic states have been freed, then use
that count later to do the appropriate number of RPM puts at the end of the
function.
Fixes: 97028037a38ae ("drm/amdgpu: Grab/put runtime PM references in
atomic_commit_tail()")
Signed-off-by: Lyude Paul
Cc: Michel Dänzer
Reported-by:
On Thu, 2018-08-02 at 21:40 +0200, Lukas Wunner wrote:
> On Wed, Aug 01, 2018 at 05:14:58PM -0400, Lyude Paul wrote:
> > We can't and don't need to try resuming the device from our hotplug
> > handlers, but hotplug events are generally something we'd like to keep
> > the devi
duplicate call in the next version of this
On Thu, 2018-08-02 at 21:14 +0200, Lukas Wunner wrote:
> On Wed, Aug 01, 2018 at 05:14:52PM -0400, Lyude Paul wrote:
> > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > @@ -592,10 +592,11 @@ no
when we know that we're just running from the
context of our hotplug interrupt handler. Since hpd interrupts are only
enabled while the device is runtime active, this should be totally safe.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
dri
nouveau_debugfs(drm) will never be NULL, because we're taking the value
of the potentially null device pointer and adding to it so it isn't 0x0.
So, check if drm is NULL instead.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 5 +++--
1 file changed
nouveau_connector_detect() is being called from the context of it's
connector's hotplug handler in order to fix the next deadlocking issue.
This is (slightly) faster anyway!
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau
This is the next version of
https://patchwork.freedesktop.org/series/46815/
With a lot more thought put into it so as to avoid the potential
deadlock scenarios I missed. This also required fixing some bogus DRM
helper usage.
Try and deadlock me now, nouveau. I dare you!!!
Lyude Paul (8):
drm
Having runtime PM makes no difference on whether or not we want polling,
and it's now safe to just enable polling unconditionally in drm_load()
thanks to d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Peter Ujfalus
finished.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau
been fixed properly in
d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")
Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling")
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Peter Ujfalusi
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm
avoiding grabbing a power reference.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
to disable hotplugging, we simply return -EBUSY so that the
runtime PM core attempts autosuspending the device again once fb_helper
isn't doing anything.
This fixes one of the issues causing deadlocks on runtime suspend/resume
with nouveau on my P50.
Signed-off-by: Lyude Paul
Cc: sta
is will let us fix the runtime
suspend/resume deadlocks that we've been experiencing with nouveau,
along with being able to fix some of the incorrect runtime PM core
interaction that other DRM drivers currently perform to work around
these issues.
Signed-off-by: Lyude Paul
Cc: sta
nouveau_debugfs(drm) will never be NULL, because we're taking the value
of the potentially null device pointer and adding to it so it isn't 0x0.
So, check if drm is NULL instead.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
---
Forgot to hit :w before committing, whoops!
drivers/gpu/drm/nouveau
userspace to
start getting mysterious keypresses from the ACPI_VIDEO_REPROBE events
that are meant for us, simply add a member to nouveau_drm that can be
used to enable/disable our ACPI event handler from being able to
schedule connector probes on it's own.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index ec7861457b84..b2a93e3fa67b 100644
--- a/drivers/gpu/drm/nouveau
nouveau_debugfs(drm) will never be NULL, because we're taking the value
of the potentially null device pointer and adding to it so it isn't 0x0.
So, check if drm is NULL instead.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
---
Changes since v2:
- Also fix nouveau_debugfs_pstate_set()
drivers
finished.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau
when we know that we're just running from the
context of our hotplug interrupt handler. Since hpd interrupts are only
enabled while the device is runtime active, this should be totally safe.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
dri
nouveau_connector_detect() is being called from the context of it's
connector's hotplug handler in order to fix the next deadlocking issue.
This is (slightly) faster anyway!
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau
_helper_resume_hotplug(), since it's possible other activity
(such as a hotplug) could be going on at the same time the driver
calls drm_fb_helper_resume_hotplug(). We need this to check whether or
not drm_fb_helper_hotplug_event() needs to be called anyway
Signed-off-by: Lyude Paul
Cc: sta.
Having runtime PM makes no difference on whether or not we want polling,
and it's now safe to just enable polling unconditionally in drm_load()
thanks to d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Peter Ujfalus
avoiding grabbing a power reference.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
to disable hotplugging, we simply return -EBUSY so that the
runtime PM core attempts autosuspending the device again once fb_helper
isn't doing anything.
This fixes one of the issues causing deadlocks on runtime suspend/resume
with nouveau on my P50.
Signed-off-by: Lyude Paul
Cc: sta
been fixed properly in
d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")
Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling")
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Peter Ujfalusi
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm
This is the latest version of
https://patchwork.freedesktop.org/series/46815/
With a bunch of fixes to the new fb_helper to prevent it from breaking
module loading/unloading with nouveau. Also; lots of documentation
fixes and one fix in response to a kbuild bot.
Lyude Paul (8):
drm/nouveau
On Thu, 2018-07-26 at 17:12 +0200, Greg KH wrote:
> On Mon, Jul 23, 2018 at 01:13:20PM -0400, Lyude Paul wrote:
> > commit eb493fbc150f4a28151ae1ee84f24395989f3600 upstream
> >
> > Currently nouveau doesn't actually expose the state debugfs file that's
> > usually p
On Mon, 2018-08-06 at 11:15 +0200, Daniel Vetter wrote:
> On Wed, Aug 01, 2018 at 05:14:57PM -0400, Lyude Paul wrote:
> > When we disable hotplugging on the GPU, we need to be able to
> > synchronize with each connector's hotplug interrupt handler before the
> > interrup
This is the latest version of https://patchwork.freedesktop.org/series/46815/
I moved everything out of fb_helper and back into nouveau, because it
seems that other drivers actually do have this handled already as far as
I can tell.
Lyude Paul (13):
drm/nouveau: Fix bogus
been fixed properly in
d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")
Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling")
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Peter Ujfalusi
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/no
Currently, it appears that nouveau_do_suspend() forgets to roll back
suspending fbcon and suspending the device LEDs. We also currently skip
the entire rollback process if nouveau_display_suspend() fails. So, fix
that.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc
Currently, there's nothing in nouveau that actually cancels this work
struct. So, cancel it on suspend/unload. Otherwise, if we're unlucky
enough hpd_work might try to keep running up until the system is
suspended.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau
when we know that we're just running from the
context of our hotplug interrupt handler. Since hpd interrupts are only
enabled while the device is runtime active, this should be totally safe.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
dri
This won't do anything but potentially make us miss hotplugs. We already
call drm_kms_helper_poll_disable() in
nouveau_pmops_suspend()->nouveau_display_suspend()->nouveau_display_fini()
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Karol Herbst
[omitting stable Cc, this likely doesn
suspend process in nouveau_do_suspend()
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm
This doesn't do anything, drm_kms_helper_poll_enable() gets called in
nouveau_pmops_resume()->nouveau_display_resume()->nouveau_display_init()
already.
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Karol Herbst
[omitting stable Cc, this likely doesn't fix any real bugs]
---
drivers/g
-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c7ec86d6c3c9..5fdc1fbe2ee5 100644
nouveau_connector_detect() is being called from the context of it's
connector's hotplug handler in order to fix the next deadlocking issue.
This is (slightly) faster anyway!
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau
Again, this doesn't do anything. drm_kms_helper_poll_enable() will have
already been called in nouveau_display_init()
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Karol Herbst
[omitting stable Cc, this probably doesn't fix any real bugs]
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +---
1
Otherwise, how will we roll everything back?
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau
avoiding grabbing a power reference.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
ce it's possible other activity
(such as a hotplug) could be going on at the same time the driver
calls drm_fb_helper_resume_hotplug(). We need this to check whether or
not drm_fb_helper_hotplug_event() needs to be called anyway
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karo
finished.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau
This doesn't do anything, drm_kms_helper_poll_enable() gets called in
nouveau_pmops_resume()->nouveau_display_resume()->nouveau_display_init()
already.
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 1 -
1 file chan
This won't do anything but potentially make us miss hotplugs. We already
call drm_kms_helper_poll_disable() in
nouveau_pmops_suspend()->nouveau_display_suspend()->nouveau_display_fini()
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Cc: Lukas Wunner
---
drivers/gpu/drm/n
Again, this doesn't do anything. drm_kms_helper_poll_enable() will have
already been called in nouveau_display_init()
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
Does what it says on the label, a lot of these calls are already handled
somewhere else and don't appear to be here for a legitimate reason
anymore.
Lyude Paul (3):
drm/nouveau: Remove useless poll_enable() call in
switcheroo_set_state()
drm/nouveau: Remove useless poll_disable() call
been fixed properly in
d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")
Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling")
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Peter Ujfalusi
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/no
-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c7ec86d6c3c9..5fdc1fbe2ee5 100644
at a hotplug occurs while the device is
suspending or resuming, we can simply defer our response until the GPU
is fully runtime resumed again.
Changes since v5:
- Use a new trick I came up with using pm_runtime_get() instead of the
hackish junk we had before
Signed-off-by: Lyude Paul
Cc:
I made (although we probably still want those changes, but not for
fixing these deadlocks) I've removed those now irrelevant patches from
the series and will resend them on their own to make reviewing this
go faster.
Lyude Paul (5):
drm/nouveau: Fix bogus drm_kms_helper_poll_enable
avoiding grabbing a power reference.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
Latest version of https://patchwork.freedesktop.org/series/46815/ , with
one small change re: ilia
Lyude Paul (5):
drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement
drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend()
drm/nouveau: Fix deadlock with fb_helper
been fixed properly in
d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")
Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling")
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Peter Ujfalusi
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/no
at a hotplug occurs while the device is
suspending or resuming, we can simply defer our response until the GPU
is fully runtime resumed again.
Changes since v4:
- Use a new trick I came up with using pm_runtime_get() instead of the
hackish junk we had before
Signed-off-by: Lyude Paul
Cc:
-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c7ec86d6c3c9..5fdc1fbe2ee5 100644
per.h when CONFIG_DRM_FBDEV_EMULATION
isn't enabled
- Actually grab the toplevel fb_helper lock in
drm_fb_helper_resume_hotplug(), since it's possible other activity
(such as a hotplug) could be going on at the same time the driver
calls drm_fb_helper_resume_hotplug(). We need this to check whether or
avoiding grabbing a power reference.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
_helper_resume_hotplug(), since it's possible other activity
(such as a hotplug) could be going on at the same time the driver
calls drm_fb_helper_resume_hotplug(). We need this to check whether or
not drm_fb_helper_hotplug_event() needs to be called anyway
Signed-off-by: Lyude Paul
Cc:
On Mon, 2018-08-13 at 15:11 -0400, Ilia Mirkin wrote:
> On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul wrote:
> > +bool
> > +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon)
> > +{
> > + bool hotplug;
> > +
> > + if (!
This doesn't do anything, drm_kms_helper_poll_enable() gets called in
nouveau_pmops_resume()->nouveau_display_resume()->nouveau_display_init()
already.
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Acked-by: Daniel Vetter
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_vga
This won't do anything but potentially make us miss hotplugs. We already
call drm_kms_helper_poll_disable() in
nouveau_pmops_suspend()->nouveau_display_suspend()->nouveau_display_fini()
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Acked-by: Daniel Vetter
Cc: Lukas Wunner
---
d
Next version of https://patchwork.freedesktop.org/series/48131/
Only changes are new A-Bs and R-Bs
Lyude Paul (3):
drm/nouveau: Remove useless poll_enable() call in
switcheroo_set_state()
drm/nouveau: Remove useless poll_disable() call in
switcheroo_set_state()
drm/nouveau: Remove
Again, this doesn't do anything. drm_kms_helper_poll_enable() will have
already been called in nouveau_display_init()
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Acked-by: Daniel Vetter
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +---
1 file changed, 1 insertion
at a hotplug occurs while the device is
suspending or resuming, we can simply defer our response until the GPU
is fully runtime resumed again.
Changes since v4:
- Use a new trick I came up with using pm_runtime_get() instead of the
hackish junk we had before
Signed-off-by: Lyude Paul
Reviewed
avoiding grabbing a power reference.
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Acked-by: Daniel Vetter
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git
been fixed properly in
d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")
Fixes: 9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling")
Signed-off-by: Lyude Paul
Acked-by: Karol Herbst
Acked-by: Daniel Vetter
Cc: Lukas Wunner
Cc: Peter Ujfalusi
Cc: sta..
). We need this to check whether or
not drm_fb_helper_hotplug_event() needs to be called anyway
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Acked-by: Daniel Vetter
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
-by: Lyude Paul
Acked-by: Karol Herbst
Acked-by: Daniel Vetter
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index
Next version of https://patchwork.freedesktop.org/series/46815/
Same as previous version, but some small changes made to commit messages
and acks/rbs have been added
Lyude Paul (5):
drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement
drm/nouveau: Remove duplicate poll_enable
us
PM ref.
This also has the added benefit of preventing redundant connector
reprobes from ACPI while the GPU is runtime resumed!
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Karol Herbst
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1477182#c41
Signed-off-by: Lyude Paul
---
driver
avoid
taking any action except if the state of the MST topology actually
changes.
This fixes MST sideband message timeouts and detection failures on my
P50 with its ThinkPad dock.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/dispnv50/disp.c
,
and module reloads.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau
This fixes some annoying issues on the P50-P52 with displays not being
detected if they aren't plugged in at boot, and sometimes even when they
are plugged in at boot.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1477182
Lyude Paul (2):
drm/nouveau: Only write DP_MSTM_CTRL when needed
On Mon, 2018-08-06 at 10:43 +0200, Daniel Vetter wrote:
> On Mon, Jul 30, 2018 at 08:39:48PM -0400, Lyude Paul wrote:
> > I'm sure I don't need to tell you that fb_helper's locking is a mess.
> > That being said; fb_helper's locking mess can seriously complicate the
> > r
ector->aux.transfer) {
With the comments I made about this on patch 1 addressed/resolved:
Reviewed-by: Lyude Paul
> + drm_dp_cec_unregister_connector(_connector->aux);
> drm_dp_aux_unregister(_connector->aux);
> + }
> kfree(connector);
>
Reviewed-by: Lyude Paul
We really need to add support for using this into the MST helpers. A good way to
test this would probably be to hook up an aux device to the DP AUX adapters we
create for each MST topology
On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote:
> From: Hans Verk
This series fixes some intermittent issues with bringing up the
dedicated GM107 GPU that I've been observing on my ThinkPad P50. More
details within.
Lyude Paul (2):
drm/nouveau: Fix GM107 disp core chan init on ThinkPad P50
drm/nouveau: Fix GM107 disp dmac chan init on ThinkPad P50
.../drm
ors on my ThinkPad P50 with a
GM107 GPU.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
Cc: sta...@vger.kernel.org
---
.../drm/nouveau/nvkm/engine/disp/coregf119.c | 21 +--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/coreg
e rest of the disp channels.
This along with the previous patch fix random initialization failures
observed with the Thinkpad P50.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
Cc: sta...@vger.kernel.org
---
.../drm/nouveau/nvkm/engine/disp/dmacgf119.c | 19 +--
1 file changed, 17 inse
On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> If aux->transfer == NULL, then just return without doing
> anything. In that case the function is likely called for
> a non-(e)DP connector.
>
> This never happened for the i915 driver, but the nouveau and amdgpu
>
Reviewed-by: Lyude Paul
On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> A big problem with DP CEC-Tunneling-over-AUX is that it is tricky
> to find adapters with a chipset that supports this AND where the
> manufacturer actually connected th
On Mon, 2018-08-20 at 22:43 +0200, Hans Verkuil wrote:
> On 08/20/2018 08:59 PM, Lyude Paul wrote:
> > Reviewed-by: Lyude Paul
> >
> > We really need to add support for using this into the MST helpers. A good
> > way to
> > test this would probably be to ho
On Mon, 2018-08-20 at 22:47 +0200, Hans Verkuil wrote:
> On 08/20/2018 08:51 PM, Lyude Paul wrote:
> > On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote:
> > > From: Hans Verkuil
> > >
> > > If aux->transfer == NULL, then just return without doing
&g
As a note: I don't think this patch is ready /just/ yet now as I just hit this
problem again this morning (and it looks like I'm checking the wrong mask for
dmac, it appears to be slightly different from the core), looking into this now
On Mon, 2018-08-20 at 13:20 -0400, Lyude Paul wrote:
> J
Still no functional changes.
Signed-off-by: Lyude Paul
Cc: Jeffery Miller
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau
on/teardown into the ->late_register() and
->early_unregister() hooks so that DRM can give us a chance to remove
the backlight before the connector is even removed. This appears to fix
the problem once and for all.
Signed-off-by: Lyude Paul
Cc: Jeffery Miller
Cc: Karol Herbst
---
drivers
This series fixes some issues with nouveau's backlight support that were
causing kernel panics on module reloads, specifically on systems with
nouveau handling the backlight of one of the displays.
While we're at it, let's cleanup nouveau_backlight.c as well
Lyude Paul (5):
drm/nouveau: Check
More consistent with the rest of the codebase, no functional changes
here.
Signed-off-by: Lyude Paul
Cc: Jeffery Miller
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.h | 4
!
Signed-off-by: Lyude Paul
Cc: Jeffery Miller
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 131 +---
1 file changed, 57 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
Remember, ida IDs start at 0, not 1!
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Jeffery Miller
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b
e for us to fail to reboot if we put both the card and
the kernel into a bad state and require a full reboot. But until then,
this patch should make the problem significantly less noticeable.
For reference, the BIOS version on this P50 is version 1.52.
Signed-off-by: Lyude Paul
Cc: Karol Herbs
We forget to free drm in all instances of failure, and additionally also
forget to destroy the master client if the other client fails
initialization.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions
op.org/series/47843/
This fixes issues with DRM connectors getting leaked on device removal,
due to hpd_work still being active when unloading nouveau.
== IMPORTANT ===
This also uncovered one small bug in nouveau_drm_load().
Lyude Paul (3):
101 - 200 of 2365 matches
Mail list logo
