similar to: [PATCH v2 6/7] drm/nouveau: Convert nouveau to use new iterator macros, v2.

Use the new atomic iterator macros, the old ones are about to be removed. With the new macros, it's more easy to get old and new state so get them from the macros instead of from obj->state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org ---

On Wed, Jul 12, 2017 at 10:13:43AM +0200, Maarten Lankhorst wrote: > Use the new atomic iterator macros, the old ones are about to be > removed. With the new macros, it's more easy to get old and new state so > get them from the macros instead of from obj->state. > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> > Cc: Ben Skeggs <bskeggs

While we're not quite ready yet to add support for flexible wndw mappings, we are going to need to at least keep track of the static wndw mappings we're currently using in each head's atomic state. We'll likely use this in the future to implement real flexible window mapping, but the primary reason we'll need this is for CRC support. See: on nvidia hardware, each CRC entry in

While we're not quite ready yet to add support for flexible wndw mappings, we are going to need to at least keep track of the static wndw mappings we're currently using in each head's atomic state. We'll likely use this in the future to implement real flexible window mapping, but the primary reason we'll need this is for CRC support. See: on nvidia hardware, each CRC entry in

While we're not quite ready yet to add support for flexible wndw mappings, we are going to need to at least keep track of the static wndw mappings we're currently using in each head's atomic state. We'll likely use this in the future to implement real flexible window mapping, but the primary reason we'll need this is for CRC support. See: on nvidia hardware, each CRC entry in

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

This fixes a kernel oops when loading the nouveau module with fb console enabled after the change: drm/nouveau: Remove field nvbo from struct nouveau_framebuffer state->fb may be NULL in nv50_wndw_prepare_fb(), so defer initializing nvbo from its obj[] array until after the NULL check. Signed-off-by: James Jones <jajones at nvidia.com> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 3

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

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 (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Update the cirrus driver to follow current best practices. While the driver's hardware is obsolete, the cirrus driver is still one of the go-to modules to learn about writing a DRM driver. So keep it in good shape. Patches 1 to 3 simplify blitting and convert it to the DRM's current helpers. Patches 4 to 8 replace simple-KMS helpers with DRM's regular atomic helpers. The former are

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

Yes, that's certainly viable. If that's the general preference in direction, I'll rework that patches to do so. Thanks, -James On 2/6/20 7:49 AM, Thomas Zimmermann wrote: > Hi James > > Am 06.02.20 um 16:17 schrieb James Jones: >> Note I'm adding some fields to nouveau_framebuffer in the series >> "drm/nouveau: Support NVIDIA format modifiers."?

Note I'm adding some fields to nouveau_framebuffer in the series "drm/nouveau: Support NVIDIA format modifiers." I sent out v3 of that yesterday. It would probably still be possible to avoid them by re-extracting the relevant data from the format modifier on the fly when needed, but it is simpler and likely less error-prone with the wrapper struct. Thanks, -James On 2/6/20

The format modifiers, when present, override the equivalent field in the BO. Right now, that's probably not particularly useful. However, as nouveau interfaces evolve towards the HW capabilities and add support for newer graphics APIs, saying an entire BO has a singular layout becomes less meaningful, so I suspect those fields will be effectively deprecated in favor of the

On Sat, 8 Feb 2020 at 07:10, James Jones <jajones at nvidia.com> wrote: > > I've sent out a v4 version of the format modifier patches which avoid > caching values in the nouveau_framebuffer struct. It will have a few > trivial conflicts with your series, but should make them structurally > compatible. > > I'm fine with either v3 or v4 of my series personally,

On 2/10/20 12:25 AM, Thomas Zimmermann wrote: > Hi > > Am 10.02.20 um 09:20 schrieb Ben Skeggs: >> On Sat, 8 Feb 2020 at 07:10, James Jones <jajones at nvidia.com> wrote: >>> >>> I've sent out a v4 version of the format modifier patches which avoid >>> caching values in the nouveau_framebuffer struct. It will have a few >>> trivial

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 (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

This adds support on GF119:GV100 (exclusive) for CTM (aka CSC). Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- v1 -> v2: - ctm -> csc - mark csc.valid = false when there is no ctm property drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++ drivers/gpu/drm/nouveau/dispnv50/base907c.c | 65 +++++++++++++++++++++ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 16 +++++

The hardware supports either size. Also add checks to ensure that only these two sizes may be used for supplying a LUT. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Only tested on G84 and GK208. The GV100+ is entirely untested. With the fixed modetest tool, setting ilut and olut sizes to different quantities seems to work out OK, across a range of formats (XR24, XB30, XB4H).

This adds support on GF119:GV100 (exclusive) for CTM (aka CSC). Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++ drivers/gpu/drm/nouveau/dispnv50/base907c.c | 65 +++++++++++++++++++++ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 13 +++++ drivers/gpu/drm/nouveau/dispnv50/wndw.h | 4 ++ 4 files changed, 88 insertions(+)