Displaying 20 results from an estimated 1000 matches similar to: "[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures"
2019 Sep 13
0
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Hi Greg,
This feels like it's missing a From: line.
commit b513a18cf1d705bd04efd91c417e79e4938be093
Author: Lyude Paul <lyude at redhat.com>
Date: Mon Jan 28 16:03:50 2019 -0500
drm/nouveau: Don't WARN_ON VCPI allocation failures
Is this an artifact of your notification-of-patches process and I
never noticed before, or was the patch ingested incorrectly?
Cheers,
-ilia
2019 Sep 03
0
[PATCH AUTOSEL 4.19 070/167] drm/nouveau: Don't WARN_ON VCPI allocation failures
From: Lyude Paul <lyude at redhat.com>
[ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ]
This is much louder then we want. VCPI allocation failures are quite
normal, since they will happen if any part of the modesetting process is
interrupted by removing the DP MST topology in question. So just print a
debugging message on VCPI failures instead.
Signed-off-by: Lyude Paul
2019 Sep 13
3
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote:
>Hi Greg,
>
>This feels like it's missing a From: line.
>
>commit b513a18cf1d705bd04efd91c417e79e4938be093
>Author: Lyude Paul <lyude at redhat.com>
>Date: Mon Jan 28 16:03:50 2019 -0500
>
> drm/nouveau: Don't WARN_ON VCPI allocation failures
>
>Is this an artifact of your
2019 Jan 28
1
[PATCH] drm/nouveau: Don't WARN_ON VCPI allocation failures
This is much louder then we want. VCPI allocation failures are quite
normal, since they will happen if any part of the modesetting process is
interrupted by removing the DP MST topology in question. So just print a
debugging message on VCPI failures instead.
Signed-off-by: Lyude Paul <lyude at redhat.com>
Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2
2019 Sep 13
4
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote:
>On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote:
>> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote:
>> > Hi Greg,
>> >
>> > This feels like it's missing a From: line.
>> >
>> > commit b513a18cf1d705bd04efd91c417e79e4938be093
>> > Author:
2019 Feb 02
6
[PATCH v3 0/4] drm/dp_mst: Fix regressions from new atomic VCPI helpers
This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.
This time around, we use a slightly different but much less complicated
approach for fixing said issues.
Cc: Daniel Vetter <daniel at ffwll.ch>
Lyude Paul (4):
drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()
2019 Sep 13
0
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote:
> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote:
> > Hi Greg,
> >
> > This feels like it's missing a From: line.
> >
> > commit b513a18cf1d705bd04efd91c417e79e4938be093
> > Author: Lyude Paul <lyude at redhat.com>
> > Date: Mon Jan 28 16:03:50 2019 -0500
> >
2019 Sep 13
0
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:01:11AM -0400, Sasha Levin wrote:
> On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote:
> > > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote:
> > > > Hi Greg,
> > > >
> > > > This feels like it's missing a From: line.
2019 Sep 13
0
[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin <sashal at kernel.org> wrote:
>
> On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote:
> >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote:
> >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote:
> >> > Hi Greg,
> >> >
> >> > This feels like it's
2019 Feb 01
6
[PATCH v2 0/4] drm/dp_mst: Fix regressions from new atomic VCPI helpers
This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.
This time around, we use a slightly different but much less complicated
approach for fixing said issues.
Cc: Daniel Vetter <daniel at ffwll.ch>
Lyude Paul (4):
drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()
2019 Feb 02
0
[PATCH v3 4/4] drm/nouveau: Move PBN and VCPI allocation into nv50_head_atom
Atomic checks should never modify anything outside of the state that
they're passed in. Unfortunately this appears to be exactly what we're
doing in nv50_msto_atomic_check() where we update mstc->pbn every time
the function is called. This hasn't caused any bugs yet, but it needs to
be fixed in order to ensure that when committing an artificially
duplicated state (like during system
2019 Nov 15
6
[PATCH 0/3] MST BPC fixes for nouveau
Realized when I moved nouveau over to using the atomic DP MST VCPI
helpers that I forgot to ensure that we clamp the BPC to 8 to make us
less likely to run out of bandwidth on a topology when enabling multiple
displays that support >8 BPC - something we want to do until we have
support for dynamically selecting the bpc based on the topology's
available bandwidth, since userspace isn't
2018 Nov 07
5
[PATCH RESEND v3 0/5] drm/dp_mst: Improve VCPI helpers, use in nouveau
[sorry about the resend-copy pasted the wrong header and I want to make
sure this doesn't get missed!]
This patchset does some cleaning up of the atomic VCPI helpers for MST,
and converts nouveau over to using them. I would have included amdgpu in
this patch as well, but at the moment moving them over to the atomic
helpers is nontrivial.
Cc: Daniel Vetter <daniel at ffwll.ch>
Lyude
2018 Nov 08
5
[PATCH v4 0/5] drm/dp_mst: Improve VCPI helpers, use in nouveau
This patchset does some cleaning up of the atomic VCPI helpers for MST,
and converts nouveau over to using them. I would have included amdgpu in
this patch as well, but at the moment moving them over to the atomic
helpers is nontrivial.
Cc: Daniel Vetter <daniel at ffwll.ch>
Lyude Paul (5):
drm/dp_mst: Add some atomic state iterator macros
drm/dp_mst: Start tracking per-port VCPI
2018 Nov 08
5
[PATCH v5 0/5] drm/dp_mst: Improve VCPI helpers, use in nouveau
This patchset does some cleaning up of the atomic VCPI helpers for MST,
and converts nouveau over to using them. I would have included amdgpu in
this patch as well, but at the moment moving them over to the atomic
helpers is nontrivial.
Cc: Daniel Vetter <daniel at ffwll.ch>
Lyude Paul (5):
drm/dp_mst: Add some atomic state iterator macros
drm/dp_mst: Start tracking per-port VCPI
2019 Aug 08
2
[PATCH] drm/nouveau: Only recalculate PBN/VCPI on mode/connector changes
I -thought- I had fixed this entirely, but it looks like that I didn't
test this thoroughly enough as we apparently still make one big mistake
with nv50_msto_atomic_check() - we don't handle the following scenario:
* CRTC #1 has n VCPI allocated to it, is attached to connector DP-4
which is attached to encoder #1. enabled=y active=n
* CRTC #1 is changed from DP-4 to DP-5, causing:
*
2018 Oct 26
8
[PATCH v2 0/4] drm/dp_mst: Improve VCPI helpers, use in nouveau
This patchset does some cleaning up of the atomic VCPI helpers for MST,
and converts nouveau over to using them. I would have included amdgpu in
this patch as well, but at the moment moving them over to the atomic
helpers is nontrivial.
Cc: Daniel Vetter <daniel at ffwll.ch>
Lyude Paul (4):
drm/dp_mst: Add some atomic state iterator macros
drm/dp_mst: Start tracking per-port VCPI
2018 Nov 16
8
[PATCH v6 0/6] drm/dp_mst: Improve VCPI helpers, use in nouveau
This patchset does some cleaning up of the atomic VCPI helpers for MST,
and converts nouveau over to using them. I would have included amdgpu in
this patch as well, but at the moment moving them over to the atomic
helpers is nontrivial.
[sorry for still not adding your R-Bs! I ended up needing to make a
lot of changes to make it so we do actually kref() each port in the
atomic state]
Cc: Daniel
2019 Aug 09
1
[PATCH v2] drm/nouveau: Only recalculate PBN/VCPI on mode/connector changes
I -thought- I had fixed this entirely, but it looks like that I didn't
test this thoroughly enough as we apparently still make one big mistake
with nv50_msto_atomic_check() - we don't handle the following scenario:
* CRTC #1 has n VCPI allocated to it, is attached to connector DP-4
which is attached to encoder #1. enabled=y active=n
* CRTC #1 is changed from DP-4 to DP-5, causing:
*
2018 Nov 17
9
[PATCH 0/6] Remove all bad dp_mst_port uses and hide struct def
So we don't ever have to worry about drivers touching drm_dp_mst_port
structs without verifying them and crashing again.
Lyude Paul (6):
drm/dp_mst: Add drm_dp_get_payload_info()
drm/nouveau: Use drm_dp_get_payload_info() for getting payload/vcpi
drm/nouveau: Stop reading port->mgr in nv50_mstc_get_modes()
drm/nouveau: Stop reading port->mgr in nv50_mstc_detect()
drm/dp_mst: