search for: nv50_crc_sourc

...e <nvif/class.h> +#include <nvif/cl0002.h> +#include <nvif/timer.h> + +#include "nouveau_drv.h" +#include "core.h" +#include "head.h" +#include "wndw.h" +#include "handles.h" +#include "crc.h" + +static const char * const nv50_crc_sources[] = { + [NV50_CRC_SOURCE_NONE] = "none", + [NV50_CRC_SOURCE_AUTO] = "auto", + [NV50_CRC_SOURCE_RG] = "rg", + [NV50_CRC_SOURCE_OUTP_ACTIVE] = "outp-active", + [NV50_CRC_SOURCE_OUTP_COMPLETE] = "outp-complete", + [NV50_CRC_SOURCE_OUTP_INACTIVE] = &q...

...drm/drm_vblank.h> + +#include <nvif/class.h> +#include <nvif/cl0002.h> + +#include "nouveau_drv.h" +#include "core.h" +#include "head.h" +#include "wndw.h" +#include "handles.h" +#include "crc.h" + +static const char * const nv50_crc_sources[] = { + [NV50_CRC_SOURCE_NONE] = "none", + [NV50_CRC_SOURCE_AUTO] = "auto", + [NV50_CRC_SOURCE_RG] = "rg", + [NV50_CRC_SOURCE_OUTP_ACTIVE] = "outp-active", + [NV50_CRC_SOURCE_OUTP_COMPLETE] = "outp-complete", + [NV50_CRC_SOURCE_OUTP_INACTIVE] = &q...

...e <nvif/class.h> +#include <nvif/cl0002.h> +#include <nvif/timer.h> + +#include "nouveau_drv.h" +#include "core.h" +#include "head.h" +#include "wndw.h" +#include "handles.h" +#include "crc.h" + +static const char * const nv50_crc_sources[] = { + [NV50_CRC_SOURCE_NONE] = "none", + [NV50_CRC_SOURCE_AUTO] = "auto", + [NV50_CRC_SOURCE_RG] = "rg", + [NV50_CRC_SOURCE_OUTP_ACTIVE] = "outp-active", + [NV50_CRC_SOURCE_OUTP_COMPLETE] = "outp-complete", + [NV50_CRC_SOURCE_OUTP_INACTIVE] = &q...

...e <nvif/class.h> +#include <nvif/cl0002.h> +#include <nvif/timer.h> + +#include "nouveau_drv.h" +#include "core.h" +#include "head.h" +#include "wndw.h" +#include "handles.h" +#include "crc.h" + +static const char * const nv50_crc_sources[] = { + [NV50_CRC_SOURCE_NONE] = "none", + [NV50_CRC_SOURCE_AUTO] = "auto", + [NV50_CRC_SOURCE_RG] = "rg", + [NV50_CRC_SOURCE_OUTP_ACTIVE] = "outp-active", + [NV50_CRC_SOURCE_OUTP_COMPLETE] = "outp-complete", + [NV50_CRC_SOURCE_OUTP_INACTIVE] = &q...

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

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 (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

...{ u8 wndw : 4; }; +/** + * struct nv50_crc_func - Functions and data for CRC support + * + * The interface used to abstract CRC support across card families that support + * it. + */ struct nv50_crc_func { + /** + * @set_src: Program the hardware to capture CRCs from the given + * &enum nv50_crc_source_type. Using NULL for the source and ctx will + * disable CRC for the given &struct nv50_head. + * + * Return 0 on success, or a negative error code. + */ int (*set_src)(struct nv50_head *, int or, enum nv50_crc_source_type, struct nv50_crc_notifier_ctx *, u32 wndw); + + /** +...

Other gpu drivers have some driver-specific documentation, so it would nice if nouveau did as well. This adds a bare-bones ReStructured Text document with sections for module parameter documentation, an overview of the driver architecture, a section for internal API documentation, and a glossary for nouveau-specific terms. To make the document a little less bare, I've included docblocks for

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,