search for: ovli

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)

cpp[BytePerPlane] can't describe the 10bit data format correctly, So we use bpp[BitPerPlane] to instead cpp. Signed-off-by: Sandy Huang <hjc at rock-chips.com> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ++++--- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git

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

We'll be rolling back more things in this function, and the way it's structured is a bit confusing. So, let's clean this up a bit and just unroll in the event of failure. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +++++++++++++++++-------- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git

We'll be rolling back more things in this function, and the way it's structured is a bit confusing. So, let's clean this up a bit and just unroll in the event of failure. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +++++++++++++++++-------- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git

We'll be rolling back more things in this function, and the way it's structured is a bit confusing. So, let's clean this up a bit and just unroll in the event of failure. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +++++++++++++++++-------- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git

On Mon, Sep 23, 2019 at 8:56 AM Sandy Huang <hjc at rock-chips.com> wrote: > > cpp[BytePerPlane] can't describe the 10bit data format correctly, > So we use bpp[BitPerPlane] to instead cpp. > > Signed-off-by: Sandy Huang <hjc at rock-chips.com> > --- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ++++--- > drivers/gpu/drm/nouveau/dispnv50/base507c.c | 4

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

On 1/5/20 5:30 PM, Ben Skeggs wrote: > On Tue, 17 Dec 2019 at 10:44, James Jones <jajones at nvidia.com> wrote: >> >> This series modifies the NV5x+ nouveau display backends to advertise >> appropriate format modifiers on their display planes in atomic mode >> setting blobs. >> >> Corresponding modifications to Mesa/userspace are available here:

Hi folks, Currently, when the device is removed (or the driver is unbound) the nouveau_drm structure de-allocated. However, it's still accessible from and used by some DRM layer callbacks. For example, file handles can be closed after the device has been removed (physically or otherwise). This series converts the Nouveau device structure to be allocated and de-allocated with the

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

Hi, [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v5.5.3, v5.4.19, v4.19.103, v4.14.170, v4.9.213, v4.4.213. v5.5.3: Failed to apply! Possible dependencies: 5ff0cb1ce253 ("drm/nouveau/kms/nv50-: Use less encoders by

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

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

On Tue, 17 Dec 2019 at 10:44, James Jones <jajones at nvidia.com> wrote: > > This series modifies the NV5x+ nouveau display backends to advertise > appropriate format modifiers on their display planes in atomic mode > setting blobs. > > Corresponding modifications to Mesa/userspace are available here: > > https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM