search for: nouveau_framebuff

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 t...

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 f...

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."? 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 an...

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, but if these > cleanup patches are taken, only v4 will work. I've taken Tomas' cleanup patches in...

...] of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and replace all references accordingly. This may require an additional cast. With this change we can already replace nouveau_user_framebuffer_destroy() and nouveau_user_framebuffer_create_handle() with generic GEM helpers. Calls to nouveau_framebuffer_new() receive a GEM object. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 19 ++++++------ drivers/gpu/drm/nouveau/dispnv04/disp.c | 21 ++++++------- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 21 +++++++------ drivers/gpu...

...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 conflicts with your series, but should make them structurally >>> compatible. >>> >>> I'm fine with either v3 or v4 of my series personally, but if these >>> cleanup patches are taken, only v4 will work. >...

...sociated with the > framebuffer? I'm not particularly knowledgeable on the topic, but there > already seem to exist some fields with very similar names in nouveau_bo. > Best, > > Roy > > On 06/02/2020 15:17, James Jones wrote: >> 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 simple...

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/nouv...

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, but if these cleanup patches are taken, only v4 will work. Thanks, -James On 2/6/20 8:45 AM, James Jones wrote: > Yes,...

...g, directly in the nouveau_bo object associated with the framebuffer? I'm not particularly knowledgeable on the topic, but there already seem to exist some fields with very similar names in nouveau_bo. Best, Roy On 06/02/2020 15:17, James Jones wrote: > 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 les...

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."? 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 er...

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 conflicts with your series, but should make them structurally >> compatible. >> >> I'm fine with either v3 or v4 of my series personally, but if these >> cleanup patches are taken, only v4 will work. > I've taken Toma...

...; > > > 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 conflicts with your series, but should make them structurally > >>> compatible. > >>> > >>> I'm fine with either v3 or v4 of my series personally, but if these > >>> cleanup patches are taken...

...fer? I'm not particularly knowledgeable on the topic, but there > > already seem to exist some fields with very similar names in nouveau_bo. > > Best, > > > > Roy > > > > On 06/02/2020 15:17, James Jones wrote: > >> 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,...

The vma field of struct nouveau_framebuffer is a special field for the the accelerated fbdev console. Hence there's at most one single instance for the active console. Moving it into struct nouveau_fbdev makes struct nouveau_framebuffer slightly smaller and brings it closer to struct drm_framebuffer. Signed-off-by: Thomas Zimmermann &...

...----- 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h b/drivers/gpu/drm/nouveau/nouveau_display.h index 6e8e66882e45..e397b3d246e5 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.h +++ b/drivers/gpu/drm/nouveau/nouveau_display.h @@ -12,11 +12,6 @@ struct nouveau_framebuffer { struct drm_framebuffer base; struct nouveau_bo *nvbo; struct nouveau_vma *vma; - u32 r_handle; - u32 r_format; - u32 r_pitch; - struct nvif_object h_base[4]; - struct nvif_object h_core; }; static inline struct nouveau_framebuffer * -- 2.25.0

...index 165f04a..599abc9 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -142,17 +142,22 @@ nouveau_user_framebuffer_create(struct drm_device *dev, if (!gem) return ERR_PTR(-ENOENT); + ret = -ENOMEM; nouveau_fb = kzalloc(sizeof(struct nouveau_framebuffer), GFP_KERNEL); if (!nouveau_fb) - return ERR_PTR(-ENOMEM); + goto err_unref; ret = nouveau_framebuffer_init(dev, nouveau_fb, mode_cmd, nouveau_gem_object(gem)); - if (ret) { - drm_gem_object_unreference(gem); - return ERR_PTR(ret); - } + if (ret) + goto err; return &nouveau_fb-...

...ers/gpu/drm/nouveau/dispnv50/wndw.c b/drivers/gpu/drm/nouveau/dispnv50/wndw.c > index 70ad64cb2d34..06c1b18479c1 100644 > --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c > @@ -43,7 +43,7 @@ nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct nouveau_framebuffer *fb) > { > struct nouveau_drm *drm = nouveau_drm(fb->base.dev); > struct nv50_wndw_ctxdma *ctxdma; > - const u8 kind = fb->nvbo->kind; > + const u8 kind = fb->kind; > const u32 handle = 0xfb000000 | kind; > struct...

...fe, and left as-is for consistency with existing code. v3: -Rebased on nouveau linux-5.6 @ 137c4ba7163ad9d5696b9fde78b1c0898a9c115b -Noted corresponding Mesa patches are production-worthy now -Better validate bo tile_mode when checking framebuffer size. v4: Do not cache kind, tile_mode in nouveau_framebuffer James Jones (3): drm/nouveau: Add format mod prop to base/ovly/nvdisp drm/nouveau: Check framebuffer size against bo drm/nouveau: Support NVIDIA format modifiers drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 +++++++ drivers/gpu/d...

...nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 832da8e0020d..fc8f5bb73ca8 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -201,7 +201,7 @@ nouveau_user_framebuffer_destroy(struct drm_framebuffer *drm_fb) struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb); if (fb->nvbo) - drm_gem_object_put_unlocked(&fb->nvbo->gem); + drm_gem_object_put_unlocked(&fb->nvbo->bo.base); drm_framebuffer_cleanup(drm_fb); kfree(fb); @@ -214,7 +214,7 @@ nouveau_user_framebuffer_create_handle(struct drm_f...