| Message ID | 20180330141138.28987-19-daniels@collabora.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Russell, On 30 March 2018 at 15:11, Daniel Stone <daniels@collabora.com> wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse those. Ping - have you had a chance to look at this? Cheers, Daniel
On Fri, Mar 30, 2018 at 03:11:33PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse those. > > Signed-off-by: Daniel Stone <daniels@collabora.com> > Cc: Russell King <linux@armlinux.org.uk> > --- > drivers/gpu/drm/armada/armada_fb.c | 23 ++++------------------- > drivers/gpu/drm/armada/armada_fb.h | 3 +-- > 2 files changed, 5 insertions(+), 21 deletions(-) Reviewed-by: Thierry Reding <treding@nvidia.com>
On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote: > Hi Russell, > > On 30 March 2018 at 15:11, Daniel Stone <daniels@collabora.com> wrote: > > Since drm_framebuffer can now store GEM objects directly, place them > > there rather than in our own subclass. As this makes the framebuffer > > create_handle and destroy functions the same as the GEM framebuffer > > helper, we can reuse those. > > Ping - have you had a chance to look at this? I haven't, I've not moved any of my trees off 4.16 yet as I've been away on vacation, and also busy dealing with Spectre for 32-bit ARM. From a quick look, it seems fine, and as I guess the autobuilders haven't complained, it probably builds okay. So it can probably be merged without much risk - if there are any problems I'll sort it out later. Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
On 17 May 2018 at 16:26, Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote: >> On 30 March 2018 at 15:11, Daniel Stone <daniels@collabora.com> wrote: >> > Since drm_framebuffer can now store GEM objects directly, place them >> > there rather than in our own subclass. As this makes the framebuffer >> > create_handle and destroy functions the same as the GEM framebuffer >> > helper, we can reuse those. >> >> Ping - have you had a chance to look at this? > > I haven't, I've not moved any of my trees off 4.16 yet as I've been > away on vacation, and also busy dealing with Spectre for 32-bit ARM. > > From a quick look, it seems fine, and as I guess the autobuilders > haven't complained, it probably builds okay. So it can probably > be merged without much risk - if there are any problems I'll sort it > out later. Thanks Russell. I did do a build test locally as well which had no complaints. I'll merge this through drm-misc. Cheers, Daniel
On Thu, May 17, 2018 at 04:41:35PM +0100, Daniel Stone wrote: > On 17 May 2018 at 16:26, Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > > On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote: > >> On 30 March 2018 at 15:11, Daniel Stone <daniels@collabora.com> wrote: > >> > Since drm_framebuffer can now store GEM objects directly, place them > >> > there rather than in our own subclass. As this makes the framebuffer > >> > create_handle and destroy functions the same as the GEM framebuffer > >> > helper, we can reuse those. > >> > >> Ping - have you had a chance to look at this? > > > > I haven't, I've not moved any of my trees off 4.16 yet as I've been > > away on vacation, and also busy dealing with Spectre for 32-bit ARM. > > > > From a quick look, it seems fine, and as I guess the autobuilders > > haven't complained, it probably builds okay. So it can probably > > be merged without much risk - if there are any problems I'll sort it > > out later. > > Thanks Russell. I did do a build test locally as well which had no > complaints. I'll merge this through drm-misc. Hi Daniel, I've not seen this go in during the last merge window, so I assume either it missed the window or it's been forgotten. Mind if I pick it up instead - I finally have armada on the way to atomic modeset conversion. Thanks.
Hi Russell, On Tue, 26 Jun 2018 at 15:49, Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > On Thu, May 17, 2018 at 04:41:35PM +0100, Daniel Stone wrote: > > Thanks Russell. I did do a build test locally as well which had no > > complaints. I'll merge this through drm-misc. > > I've not seen this go in during the last merge window, so I assume > either it missed the window or it's been forgotten. Mind if I pick > it up instead - I finally have armada on the way to atomic modeset > conversion. Thanks for chasing this up! AFAICT it has been merged though though: it went into drm-misc-next last month, which Dave merged into drm-next with f4366e44efeb895c. Cheers, Daniel
diff --git a/drivers/gpu/drm/armada/armada_fb.c b/drivers/gpu/drm/armada/armada_fb.c index ac92bce07ecd..edd15126bde9 100644 --- a/drivers/gpu/drm/armada/armada_fb.c +++ b/drivers/gpu/drm/armada/armada_fb.c @@ -7,30 +7,15 @@ */ #include <drm/drm_crtc_helper.h> #include <drm/drm_fb_helper.h> +#include <drm/drm_gem_framebuffer_helper.h> #include "armada_drm.h" #include "armada_fb.h" #include "armada_gem.h" #include "armada_hw.h" -static void armada_fb_destroy(struct drm_framebuffer *fb) -{ - struct armada_framebuffer *dfb = drm_fb_to_armada_fb(fb); - - drm_framebuffer_cleanup(&dfb->fb); - drm_gem_object_put_unlocked(&dfb->obj->obj); - kfree(dfb); -} - -static int armada_fb_create_handle(struct drm_framebuffer *fb, - struct drm_file *dfile, unsigned int *handle) -{ - struct armada_framebuffer *dfb = drm_fb_to_armada_fb(fb); - return drm_gem_handle_create(dfile, &dfb->obj->obj, handle); -} - static const struct drm_framebuffer_funcs armada_fb_funcs = { - .destroy = armada_fb_destroy, - .create_handle = armada_fb_create_handle, + .destroy = drm_gem_fb_destroy, + .create_handle = drm_gem_fb_create_handle, }; struct armada_framebuffer *armada_framebuffer_create(struct drm_device *dev, @@ -78,7 +63,7 @@ struct armada_framebuffer *armada_framebuffer_create(struct drm_device *dev, dfb->fmt = format; dfb->mod = config; - dfb->obj = obj; + dfb->fb.obj[0] = &obj->obj; drm_helper_mode_fill_fb_struct(dev, &dfb->fb, mode); diff --git a/drivers/gpu/drm/armada/armada_fb.h b/drivers/gpu/drm/armada/armada_fb.h index 48073c4f54d8..5c130ff5da77 100644 --- a/drivers/gpu/drm/armada/armada_fb.h +++ b/drivers/gpu/drm/armada/armada_fb.h @@ -10,13 +10,12 @@ struct armada_framebuffer { struct drm_framebuffer fb; - struct armada_gem_object *obj; uint8_t fmt; uint8_t mod; }; #define drm_fb_to_armada_fb(dfb) \ container_of(dfb, struct armada_framebuffer, fb) -#define drm_fb_obj(fb) drm_fb_to_armada_fb(fb)->obj +#define drm_fb_obj(fb) drm_to_armada_gem((fb)->obj[0]) struct armada_framebuffer *armada_framebuffer_create(struct drm_device *, const struct drm_mode_fb_cmd2 *, struct armada_gem_object *);
Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <daniels@collabora.com> Cc: Russell King <linux@armlinux.org.uk> --- drivers/gpu/drm/armada/armada_fb.c | 23 ++++------------------- drivers/gpu/drm/armada/armada_fb.h | 3 +-- 2 files changed, 5 insertions(+), 21 deletions(-)