Displaying 20 results from an estimated 800 matches similar to: "[PATCH 2/6] drm/nouveau: Unbreak nv50_mstc->best_encoder()"
2018 Sep 19
0
[PATCH v2 2/6] drm/nouveau: Unbreak nv50_mstc->best_encoder()
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable CRTCs on MST connectors after the connector's respective
topology has disappeared.
So, fix this
2018 Oct 05
0
[PATCH v4 2/5] drm/nouveau: Fix nv50_mstc->best_encoder()
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable CRTCs on MST connectors after the connector's respective
topology has disappeared.
So, fix this
2019 Sep 13
1
[PATCH 2/4] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
On Fri, Sep 13, 2019 at 6:05 PM Lyude Paul <lyude at redhat.com> wrote:
>
> When drm_connector_helper_funcs->atomic_best_encoder is defined,
> ->best_encoder is ignored both by the atomic modesetting helpers. That
By both the atomic modesetting helpers and ... (usually "both" implies 2 things)
> being said, this hook is completely broken anyway - it always
2019 Sep 13
0
[PATCH 2/4] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
When drm_connector_helper_funcs->atomic_best_encoder is defined,
->best_encoder is ignored both by the atomic modesetting helpers. That
being said, this hook is completely broken anyway - it always returns
the first msto for a given mstc, despite the fact it might already be in
use.
So, just get rid of it. We'll need this in a moment anyway, when we make
mstos per-head as opposed to
2018 Dec 14
0
[WIP PATCH 15/15] drm/nouveau: Use atomic VCPI helpers for MST
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actually check whether or not the topology still has
enough bandwidth to provide the VCPI
2018 Oct 26
0
[PATCH v2 4/4] drm/nouveau: Use atomic VCPI helpers for MST
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actually check whether or not the topology still has
enough bandwidth to provide the VCPI
2018 Dec 14
0
[WIP PATCH 10/15] drm/nouveau: Stop unsetting mstc->port, use malloc refs
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul <lyude at redhat.com>
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 +++++-------------
1
2018 Nov 17
0
[PATCH 2/6] drm/nouveau: Use drm_dp_get_payload_info() for getting payload/vcpi
Currently, nouveau tries to go through the drm_dp_mst_port structures
itself in order to retrieve the relevant payload and VCPI information
that it needs to report to the GPU. This is wrong: mstc->port could be
destroyed at any point, and additionally the payload could be changed at
any point because it doesn't bother trying to grab the payload lock. So;
remove nv50_msto_payload entirely
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
2018 Dec 14
0
[WIP PATCH 08/15] drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks are meant to protect against.
More importantly though, we're about to stop clearing
2019 Oct 22
0
[PATCH v5 06/14] drm/dp_mst: Protect drm_dp_mst_port members with locking
This is a complicated one. Essentially, there's currently a problem in the MST
core that hasn't really caused any issues that we're aware of (emphasis on "that
we're aware of"): locking.
When we go through and probe the link addresses and path resources in a
topology, we hold no locks when updating ports with said information. The
members I'm referring to in
2020 Nov 14
0
[PATCH 6/8] drm/nouveau/kms/nv50-: Lookup current encoder/crtc from atomic state
Despite being an atomic driver, nouveau has a lot of leftover code that
relies on retrieving information regarding the new atomic state from
members of drm_encoder and drm_crtc. The first field being used,
drm_encoder.crtc, is deprecated for atomic drivers. The second field being
used is drm_crtc.state, which is only really sensible to use outside of an
atomic modeset.
So, add some helpers to
2020 Nov 14
0
[PATCH 4/8] drm/nouveau/kms/nv50-: s/armh/asyh/ in nv50_msto_atomic_enable()
I have a strange dejavu feeling that I tried to submit a patch for this in
the past, but that it was rejected. I can't remember though, but I'm
further convinced this patch is the right thing to do anyway.
We label the to-be-committed head state in nv50_msto_atomic_enable() as
armh. Normally armh implies a state which is currently armed in hardware.
nv50_msto_atomic_enable() is called
2020 Nov 14
0
[PATCH 3/8] drm/nouveau/kms/nv50-: Rename encoder->atomic_(enable|disable) callbacks
No functional changes, just change the function names to match the
callbacks they provide.
Signed-off-by: Lyude Paul <lyude at redhat.com>
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 33 ++++++++++++-------------
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index
2020 Nov 14
1
[PATCH 1/8] drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere
It turns out that I forgot to go through and make sure that I converted all
encoder callbacks to use atomic_enable/atomic_disable(), so let's go and
actually do that.
Signed-off-by: Lyude Paul <lyude at redhat.com>
Cc: Kirill A. Shutemov <kirill at shutemov.name>
Fixes: 09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors properly")
---
2018 Sep 14
1
[PATCH] drm/nouveau: Grab runtime PM ref in nv50_mstc_detect()
While we currently grab a runtime PM ref in nouveau's normal connector
detection code, we apparently don't do this for MST. This means if we're
in a scenario where the GPU is suspended and userspace attempts to do a
connector probe on an MSTC connector, the probe will fail entirely due
to the DP aux channel and GPU not being woken up:
[ 316.633489] nouveau 0000:01:00.0: i2c: aux
2017 Aug 17
0
[PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto
On Thu, Aug 17, 2017 at 6:03 PM, Colin King <colin.king at canonical.com> wrote:
> From: Colin Ian King <colin.king at canonical.com>
>
> The null check on the array msto is incorrect since msto is never
> null. The null check should be instead on msto[i] since this is
> being dereferenced in the call to drm_mode_connector_attach_encoder.
>
> Thanks to Emil Velikov
2017 Aug 17
0
[PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto
On 08/18/2017 08:16 AM, Colin Ian King wrote:
> On 17/08/17 23:07, Ilia Mirkin wrote:
>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King <colin.king at canonical.com> wrote:
>>> From: Colin Ian King <colin.king at canonical.com>
>>>
>>> The null check on the array msto is incorrect since msto is never
>>> null. The null check should be instead
2019 May 11
0
[PATCH v3 04/10] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
Hi Sean,
Thank you for the patch.
On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> From: Sean Paul <seanpaul at chromium.org>
>
> Everyone who implements connector_helper_funcs->atomic_check reaches
> into the connector state to get the atomic state. Instead of continuing
> this pattern, change the callback signature to just give atomic state
> and let the
2019 May 08
0
[PATCH v4 04/11] drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state
From: Sean Paul <seanpaul at chromium.org>
Everyone who implements connector_helper_funcs->atomic_check reaches
into the connector state to get the atomic state. Instead of continuing
this pattern, change the callback signature to just give atomic state
and let the driver determine what it does and does not need from it.
Eventually all atomic functions should do this, but that's