search for: nv50_crc

...atom, state) #include <drm/drm_atomic.h> +#include "crc.h" + +struct nouveau_encoder; struct nv50_atom { struct drm_atomic_state state; @@ -115,9 +118,12 @@ struct nv50_head_atom { u8 nhsync:1; u8 nvsync:1; u8 depth:4; + u8 crc_raster:2; u8 bpc; } or; + struct nv50_crc_atom crc; + /* Currently only used for MST */ struct { int pbn; @@ -135,6 +141,7 @@ struct nv50_head_atom { bool ovly:1; bool dither:1; bool procamp:1; + bool crc:1; bool or:1; }; u16 mask; @@ -150,6 +157,19 @@ nv50_head_atom_get(struct drm_atomic_state *state, struct...

...atom, state) #include <drm/drm_atomic.h> +#include "crc.h" + +struct nouveau_encoder; struct nv50_atom { struct drm_atomic_state state; @@ -115,9 +118,12 @@ struct nv50_head_atom { u8 nhsync:1; u8 nvsync:1; u8 depth:4; + u8 crc_raster:2; u8 bpc; } or; + struct nv50_crc_atom crc; + /* Currently only used for MST */ struct { int pbn; @@ -135,6 +141,7 @@ struct nv50_head_atom { bool ovly:1; bool dither:1; bool procamp:1; + bool crc:1; bool or:1; }; u16 mask; @@ -150,6 +157,19 @@ nv50_head_atom_get(struct drm_atomic_state *state, struct...

...atom, state) #include <drm/drm_atomic.h> +#include "crc.h" + +struct nouveau_encoder; struct nv50_atom { struct drm_atomic_state state; @@ -115,9 +118,12 @@ struct nv50_head_atom { u8 nhsync:1; u8 nvsync:1; u8 depth:4; + u8 crc_raster:2; u8 bpc; } or; + struct nv50_crc_atom crc; + /* Currently only used for MST */ struct { int pbn; @@ -135,6 +141,7 @@ struct nv50_head_atom { bool ovly:1; bool dither:1; bool procamp:1; + bool crc:1; bool or:1; }; u16 mask; @@ -150,6 +157,19 @@ nv50_head_atom_get(struct drm_atomic_state *state, struct...

...atom, state) #include <drm/drm_atomic.h> +#include "crc.h" + +struct nouveau_encoder; struct nv50_atom { struct drm_atomic_state state; @@ -115,9 +118,12 @@ struct nv50_head_atom { u8 nhsync:1; u8 nvsync:1; u8 depth:4; + u8 crc_raster:2; u8 bpc; } or; + struct nv50_crc_atom crc; + /* Currently only used for MST */ struct { int pbn; @@ -135,6 +141,7 @@ struct nv50_head_atom { bool ovly:1; bool dither:1; bool procamp:1; + bool crc:1; bool or:1; }; u16 mask; @@ -150,6 +157,19 @@ nv50_head_atom_get(struct drm_atomic_state *state, struct...

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

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

...mands 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 flush before the OR is re-enabled regardless of the final state of CRC reporting. So, split nv50_crc_atomic_prepare_notifier_contexts() into two functions: * nv_crc_atomic_release_notifier_contexts() - checks whether the CRC notifier contexts were released successfully after the first flush * nv_crc_atomic_init_notifier_contexts() - prepares any CRC notifier contexts for use before enabling re...

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

...ispnv50/crc.h:109:54: warning: no return statement in function returning non-void [-Wreturn-type] static inline int nv50_head_crc_late_register(struct nv50_head *) {} ^~~~~~~~~ /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function ?nv50_crc_handle_vblank?: /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:111:57: warning: ?return? with a value, in function returning void nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } ^ /scratch/linux/drivers/gpu/drm/nouveau/di...

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

...ning: no > return statement in function returning non-void [-Wreturn-type] > static inline int nv50_head_crc_late_register(struct nv50_head *) {} > ^~~~~~~~~ > /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function > ?nv50_crc_handle_vblank?: > /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:111:57: warning: > ?return? with a value, in function returning void > nv50_crc_handle_vblank(struct nv50_head *head) { return 0; } > ^ > /scratch/linux/d...

Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me,

Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me,