Displaying 20 results from an estimated 900 matches similar to: "[PATCH 15/16] drm/nouveau: Convert nouveau to use new iterator macros"
2017 Jul 19
1
[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.
Changes since v1:
- Don't mix up old and new state. (danvet)
- Rebase on top of interruptible swap_state changes.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
Cc:
2017 Jul 13
0
[Intel-gfx] [PATCH 15/16] drm/nouveau: Convert nouveau to use new iterator macros
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
2020 Apr 17
9
[RFC v3 00/11] drm/nouveau: Introduce CRC support for gf119+
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
2020 May 08
16
[RFC v4 00/12] drm/nouveau: Introduce CRC support for gf119+
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
2020 Mar 18
0
[PATCH 6/9] drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom
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
2020 Apr 17
0
[RFC v3 08/11] drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom
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
2020 May 08
0
[RFC v4 09/12] drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom
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
2020 Feb 06
5
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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
2020 Mar 18
12
[PATCH 0/9] drm/nouveau: Introduce CRC support for gf119+
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
2020 Feb 06
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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."?
2018 Sep 19
1
[PATCH v2 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()
Currently the way that we prevent userspace from performing new modesets
on MST connectors that have just been destroyed is rather broken.
There's nothing in the actual DRM DP MST topology helpers that checks
whether or not a connector still exists, instead each DRM driver does
this on it's own, usually by returning NULL from the best_encoder
callback which in turn, causes the atomic
2020 Feb 06
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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
2020 Feb 10
2
[PATCH] drm/nouveau: Fix NULL ptr access in nv50_wndw_prepare_fb()
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
2020 Feb 10
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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,
2020 Feb 10
2
[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer
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
2020 Feb 06
5
[PATCH 0/4] drm/nouveau: Remove struct nouveau_framebuffer
All fields in struct nouveau_framebuffer appear to be obsolete. The
data structure can be replaced by struct drm_framebuffer entirely.
Patch 1 removes several unused fields from struct nouveau_framebuffer.
Patch 2 moves the field vma to struct nouveau_fbdev. The information
in vma is only relevant for fbdev emulation, and as such he field is
only used there.
Patch 3 removes nvbo from struct
2018 Sep 18
4
[PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()
Currently the way that we prevent userspace from performing new modesets
on MST connectors that have just been destroyed is rather broken.
There's nothing in the actual DRM DP MST topology helpers that checks
whether or not a connector still exists, instead each DRM driver does
this on it's own, usually by returning NULL from the best_encoder
callback which in turn, causes the atomic
2019 Sep 23
1
[PATCH 13/36] drm/nouveau: use bpp instead of cpp for drm_format_info
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
2020 Jun 22
13
[RFC v5 00/10] drm/nouveau: Introduce CRC support for gf119+
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
2020 Jun 24
13
[RFC v7 00/11] drm/nouveau: Introduce CRC support for gf119+
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