similar to: [PATCH 4/8] drm/nouveau/kms/nv50-: s/armh/asyh/ in nv50_msto_atomic_enable()

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

In order to be able to use bpc values that are different from what the connector reports, we want to be able to store the bpc value we decide on using for an atomic state in nv50_head_atom and refer to that instead of simply using the value that the connector reports throughout the whole atomic check phase and commit phase. This will let us (eventually) implement the max bpc connector property,

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") ---

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

We refer to the armed hardware assembly as armh elsewhere in nouveau, so fix the naming here to make it consistent. This patch contains no functional changes. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c

We refer to the armed hardware assembly as armh elsewhere in nouveau, so fix the naming here to make it consistent. This patch contains no functional changes. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c

We refer to the armed hardware assembly as armh elsewhere in nouveau, so fix the naming here to make it consistent. This patch contains no functional changes. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c

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

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both

This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both

While I had thought I'd tested this before, it looks like this one issue slipped by my original CRC patches. Basically, there seem to be a few rules we need to follow when sending CRC commands to the display controller: * CRCs cannot be both disabled and enabled for a single head in the same flush * If a head with CRC reporting enabled switches from one OR to another, there must be a

nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom struct. This patch adds copying of struct member named "or", which previously was left uninitialized in the duplicated structure. Due to this bug, incorrect nhsync and nvsync values were sometimes used. In my particular case, that lead to a mismatch between the output resolution of the graphics device (GeForce GT 630 OEM)

On Sun, 12 May 2019 at 04:23, Peteris Rudzusiks <peteris.rudzusiks at gmail.com> wrote: > > nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom > struct. This patch adds copying of struct member named "or", which > previously was left uninitialized in the duplicated structure. > > Due to this bug, incorrect nhsync and nvsync values were sometimes

From: Peteris Rudzusiks <peteris.rudzusiks at gmail.com> [ Upstream commit c4a52d669690423ee3c99d8eda1e69cd0821fcad ] nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom struct. This patch adds copying of struct member named "or", which previously was left uninitialized in the duplicated structure. Due to this bug, incorrect nhsync and nvsync values were sometimes

On Tue, May 14, 2019 at 04:55:05PM +1000, Ben Skeggs wrote: > On Sun, 12 May 2019 at 04:23, Peteris Rudzusiks > <peteris.rudzusiks at gmail.com> wrote: > > > > nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom > > struct. This patch adds copying of struct member named "or", which > > previously was left uninitialized in the duplicated

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

* Frame-packing modes add an extra vtotal raster lines to each frame above and beyond what the basic mode description calls for. Account for this during scaler configuration (possibly a bit of a hack), during CRTC configuration (clearly not a hack), and when checking that a mode is vaild for a given connector (cribbed from the i915 driver). Signed-off-by: Alastair Bridgewater

Just to be more consistent with the order of args that DRM helpers like drm_atomic_get_new_crtc_state() use. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++++++--------- drivers/gpu/drm/nouveau/nouveau_encoder.h | 6 ++---- 2 files changed, 8 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c