search for: nouveau_framebuffer_new

...+ > + if (drm->client.device.info.chipset >= 0xc0) > + *tile_mode <<= 4; > + } > + > + return 0; > +} > + > static inline uint32_t > nouveau_get_width_in_blocks(uint32_t stride) > { > @@ -300,6 +344,8 @@ nouveau_framebuffer_new(struct drm_device *dev, > struct nouveau_framebuffer *fb; > const struct drm_format_info *info; > unsigned int width, height, i; > + uint32_t tile_mode; > + uint8_t kind; > int ret; > > /* YUV overlays have special require...

...gt; > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c > index bbbff55eb5d5..94f7fd48e1cf 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_display.c > +++ b/drivers/gpu/drm/nouveau/nouveau_display.c > @@ -207,10 +207,10 @@ int > nouveau_framebuffer_new(struct drm_device *dev, > const struct drm_mode_fb_cmd2 *mode_cmd, > struct drm_gem_object *gem, > - struct nouveau_framebuffer **pfb) > + struct drm_framebuffer **pfb) > { > struct nouveau_drm *drm = nouveau_drm(dev); > - struct nouveau_framebuffer *fb; >...

...de 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 cleanup, struct nouveau_...

...> + offset, stride, h, tile_mode, bw, bh, gob_size, bl_size, > + nvbo->bo.mem.size); > + > + if (bl_size + offset > nvbo->bo.mem.size) > + return -ERANGE; > + > + return 0; > +} > + > int > nouveau_framebuffer_new(struct drm_device *dev, > const struct drm_mode_fb_cmd2 *mode_cmd, > @@ -232,6 +298,8 @@ nouveau_framebuffer_new(struct drm_device *dev, > { > struct nouveau_drm *drm = nouveau_drm(dev); > struct nouveau_framebuffer *fb; > + const str...

...gt;> 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 > >>&...

...] 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/drm/n...

...re 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 >>>>> >>>>>> &g...

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

...ile_mode = (uint32_t)(modifier & 0xF); + *kind = (uint8_t)((modifier >> 12) & 0xFF); + + if (drm->client.device.info.chipset >= 0xc0) + *tile_mode <<= 4; + } + + return 0; +} + static inline uint32_t nouveau_get_width_in_blocks(uint32_t stride) { @@ -300,6 +344,8 @@ nouveau_framebuffer_new(struct drm_device *dev, struct nouveau_framebuffer *fb; const struct drm_format_info *info; unsigned int width, height, i; + uint32_t tile_mode; + uint8_t kind; int ret; /* YUV overlays have special requirements pre-NV50 */ @@ -322,6 +368,18 @@ nouveau_framebuffer_new(struct drm_...

...au_display.c >>> b/drivers/gpu/drm/nouveau/nouveau_display.c >>> index bbbff55eb5d5..94f7fd48e1cf 100644 >>> --- a/drivers/gpu/drm/nouveau/nouveau_display.c >>> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c >>> @@ -207,10 +207,10 @@ int >>> ? nouveau_framebuffer_new(struct drm_device *dev, >>> ????????????? const struct drm_mode_fb_cmd2 *mode_cmd, >>> ????????????? struct drm_gem_object *gem, >>> -??????????? struct nouveau_framebuffer **pfb) >>> +??????????? struct drm_framebuffer **pfb) >>> ? { >>> ?????...

...evice.info.chipset >= 0xc0) >> + *tile_mode <<= 4; >> + } >> + >> + return 0; >> +} >> + >> static inline uint32_t >> nouveau_get_width_in_blocks(uint32_t stride) >> { >> @@ -300,6 +344,8 @@ nouveau_framebuffer_new(struct drm_device *dev, >> struct nouveau_framebuffer *fb; >> const struct drm_format_info *info; >> unsigned int width, height, i; >> + uint32_t tile_mode; >> + uint8_t kind; >> int ret; >> >>...

...uffer 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 cleanup, struct nouveau_framebuffer is only a wrapper around >> struct drm_frame...

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available here: https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work But those need a bit of cleanup before they're ready to submit. I've tested this on Tesla, Kepler, Pascal,

...re 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:...

...MS("offset=%u stride=%u h=%u tile_mode=0x%02x bw=%u bh=%u gob_size=%u bl_size=%llu size=%lu\n", + offset, stride, h, tile_mode, bw, bh, gob_size, bl_size, + nvbo->bo.mem.size); + + if (bl_size + offset > nvbo->bo.mem.size) + return -ERANGE; + + return 0; +} + int nouveau_framebuffer_new(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cmd, @@ -232,6 +298,8 @@ nouveau_framebuffer_new(struct drm_device *dev, { struct nouveau_drm *drm = nouveau_drm(dev); struct nouveau_framebuffer *fb; + const struct drm_format_info *info; + unsigned int width, height, i; int re...

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available here: https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work But those need a bit of cleanup before they're ready to submit. I've tested this on Tesla, Kepler, Pascal,

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available on the Mesa-dev mailing list as the series: nouveau: Improved format modifier support I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware using various formats

...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, >>&...

...f (!asyw->state.fb) return 0; diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index bbbff55eb5d5..94f7fd48e1cf 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -207,10 +207,10 @@ int nouveau_framebuffer_new(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object *gem, - struct nouveau_framebuffer **pfb) + struct drm_framebuffer **pfb) { struct nouveau_drm *drm = nouveau_drm(dev); - struct nouveau_framebuffer *fb; + struct drm_framebuffer *fb; int ret;...

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