search for: drm_framebuff

Because all drivers currently use gem objects for framebuffer planes, the virtual create_handle() is not required. This change adds a struct drm_gem_object *gems[4] field to drm_framebuffer and removes create_handle() function pointer from drm_framebuffer_funcs. The corresponding *_create_handle() function is removed from each driver. In many cases this change eliminates a struct *_framebuffer object, as the only need for the derived struct is the addition of the gem object pointe...

Because all drivers currently use gem objects for framebuffer planes, the virtual create_handle() is not required. This change adds a struct drm_gem_object *gems[4] field to drm_framebuffer and removes create_handle() function pointer from drm_framebuffer_funcs. The corresponding *_create_handle() function is removed from each driver. In many cases this change eliminates a struct *_framebuffer object, as the only need for the derived struct is the addition of the gem object pointe...

Because all drivers currently use gem objects for framebuffer planes, the virtual create_handle() is not required. This change adds a struct drm_gem_object *gems[4] field to drm_framebuffer and removes create_handle() function pointer from drm_framebuffer_funcs. The corresponding *_create_handle() function is removed from each driver. In many cases this change eliminates a struct *_framebuffer object, as the only need for the derived struct is the addition of the gem object pointe...

...plane 0 only. Signed-off-by: Joe Kniss <djmk at google.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +- drivers/gpu/drm/armada/armada_fb.c | 1 + drivers/gpu/drm/drm_crtc_internal.h | 2 + drivers/gpu/drm/drm_fb_cma_helper.c | 11 ++-- drivers/gpu/drm/drm_framebuffer.c | 79 ++++++++++++++++++++++++++++- drivers/gpu/drm/drm_ioctl.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fb.c | 7 ++- drivers/gpu/drm/gma500/framebuffer.c | 2 + drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_fb.c...

Den 09.08.2017 01.42, skrev Joe Kniss: > Because all drivers currently use gem objects for framebuffer planes, > the virtual create_handle() is not required. This change adds a > struct drm_gem_object *gems[4] field to drm_framebuffer and removes > create_handle() function pointer from drm_framebuffer_funcs. The > corresponding *_create_handle() function is removed from each driver. > > In many cases this change eliminates a struct *_framebuffer object, > as the only need for the derived struct is the addition...

...es <noralf at tronnes.org> wrote: > > Den 09.08.2017 01.42, skrev Joe Kniss: >> >> Because all drivers currently use gem objects for framebuffer planes, >> the virtual create_handle() is not required. This change adds a >> struct drm_gem_object *gems[4] field to drm_framebuffer and removes >> create_handle() function pointer from drm_framebuffer_funcs. The >> corresponding *_create_handle() function is removed from each driver. >> >> In many cases this change eliminates a struct *_framebuffer object, >> as the only need for the derived str...

...es <noralf at tronnes.org> wrote: > > Den 09.08.2017 01.42, skrev Joe Kniss: >> >> Because all drivers currently use gem objects for framebuffer planes, >> the virtual create_handle() is not required. This change adds a >> struct drm_gem_object *gems[4] field to drm_framebuffer and removes >> create_handle() function pointer from drm_framebuffer_funcs. The >> corresponding *_create_handle() function is removed from each driver. >> >> In many cases this change eliminates a struct *_framebuffer object, >> as the only need for the derived str...

...es <noralf at tronnes.org> wrote: > > Den 09.08.2017 01.42, skrev Joe Kniss: >> >> Because all drivers currently use gem objects for framebuffer planes, >> the virtual create_handle() is not required. This change adds a >> struct drm_gem_object *gems[4] field to drm_framebuffer and removes >> create_handle() function pointer from drm_framebuffer_funcs. The >> corresponding *_create_handle() function is removed from each driver. >> >> In many cases this change eliminates a struct *_framebuffer object, >> as the only need for the derived str...

...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 2:19 AM, Thomas Zimmermann wrote: > After its cleanup, struct nouveau_framebuffer is only a wrapper around > struct drm_framebuffer. Use the latter directly. > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> > --- > drivers/gpu/drm/nouveau/dispnv50/wndw.c | 26 +++++++++++------------ > drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++++++------ > drivers/gpu/drm/nouveau/nouveau_dis...

...your patchset. I think struct nouveau_framebuffer > should not store tile_mode and kind. AFAICT there are only two trivial > places where these values are used and they can be extracted from the > framebuffer at any time. > > I'd suggest to expand nouveau_decode_mod() to take a drm_framebuffer and > return the correct values. Kind of what you do in > nouveau_framebuffer_new() near line 330. > > Thoughts? > > Best regards > Thomas > > [1] https://patchwork.freedesktop.org/series/70786/#rev3 > >> >> Thanks, >> -James >> >> O...

...buffer > >> should not store tile_mode and kind. AFAICT there are only two trivial > >> places where these values are used and they can be extracted from the > >> framebuffer at any time. > >> > >> I'd suggest to expand nouveau_decode_mod() to take a drm_framebuffer and > >> return the correct values. Kind of what you do in > >> nouveau_framebuffer_new() near line 330. > >> > >> Thoughts? > >> > >> Best regards > >> Thomas > >> > >> [1] https://patchwork.freedesktop.org/series/7...

...en needed, but it is simpler and likely less error-prone with the >> wrapper struct. >> >> Thanks, >> -James >> >> On 2/6/20 2:19 AM, Thomas Zimmermann wrote: >>> After its cleanup, struct nouveau_framebuffer is only a wrapper around >>> struct drm_framebuffer. Use the latter directly. >>> >>> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> >>> --- >>> ? drivers/gpu/drm/nouveau/dispnv50/wndw.c?? | 26 +++++++++++------------ >>> ? drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++++++------ &gt...

...not store tile_mode and kind. AFAICT there are only two trivial >>>>> places where these values are used and they can be extracted from the >>>>> framebuffer at any time. >>>>> >>>>> I'd suggest to expand nouveau_decode_mod() to take a drm_framebuffer and >>>>> return the correct values. Kind of what you do in >>>>> nouveau_framebuffer_new() near line 330. >>>>> >>>>> Thoughts? >>>>> >>>>> Best regards >>>>> Thomas >>>>> >...

...deletions(-) diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h index 6f84380757ee..3532b76c2340 100644 --- a/include/drm/drm_format_helper.h +++ b/include/drm/drm_format_helper.h @@ -15,17 +15,20 @@ struct drm_rect; void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb, struct drm_rect *clip); -void drm_fb_memcpy_dstclip(void *dst, void *vaddr, struct drm_framebuffer *fb, +void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr, + struct drm_framebuffer *fb, struct drm_rect *clip); void drm_fb_swab16(u16 *dst, void *vaddr, struct drm_fr...

....org> wrote: >> >> Den 09.08.2017 01.42, skrev Joe Kniss: >>> >>> Because all drivers currently use gem objects for framebuffer planes, >>> the virtual create_handle() is not required. This change adds a >>> struct drm_gem_object *gems[4] field to drm_framebuffer and removes >>> create_handle() function pointer from drm_framebuffer_funcs. The >>> corresponding *_create_handle() function is removed from each driver. >>> >>> In many cases this change eliminates a struct *_framebuffer object, >>> as the only need...

...h amongst other things > supports multi-planar framebuffers as well as modifiers. getfb > currently calls the framebuffer's handle_create hook, which doesn't > support multiple planes. > > Thanks to Noralf's recent work, drivers can just store GEM objects > directly in drm_framebuffer. I use this directly in getfb2: we need > direct access to the GEM objects and not a vfunc in order to not hand > out duplicate GEM names for the same object. > > This series converts all drivers except for nouveau, which was a > little too non-trivial for my comfort, to storing GE...

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 nouveau_framebuffer. The...

After its cleanup, struct nouveau_framebuffer is only a wrapper around struct drm_framebuffer. Use the latter directly. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 26 +++++++++++------------ drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++++++------ drivers/gpu/drm/nouveau/nouveau_display.h | 12 +---------- drivers/...

...e. I just took a look at your patchset. I think struct nouveau_framebuffer should not store tile_mode and kind. AFAICT there are only two trivial places where these values are used and they can be extracted from the framebuffer at any time. I'd suggest to expand nouveau_decode_mod() to take a drm_framebuffer and return the correct values. Kind of what you do in nouveau_framebuffer_new() near line 330. Thoughts? Best regards Thomas [1] https://patchwork.freedesktop.org/series/70786/#rev3 > > Thanks, > -James > > On 2/6/20 2:19 AM, Thomas Zimmermann wrote: >> After its cleanu...

...hink struct nouveau_framebuffer >> should not store tile_mode and kind. AFAICT there are only two trivial >> places where these values are used and they can be extracted from the >> framebuffer at any time. >> >> I'd suggest to expand nouveau_decode_mod() to take a drm_framebuffer and >> return the correct values. Kind of what you do in >> nouveau_framebuffer_new() near line 330. >> >> Thoughts? >> >> Best regards >> Thomas >> >> [1] https://patchwork.freedesktop.org/series/70786/#rev3 >> >>> >>>...