Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

2018-06-27 Thread Daniel Stone 
Hi Russell,
On Tue, 26 Jun 2018 at 15:49, Russell King - ARM Linux
 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

2018-06-27 Thread Russell King - ARM Linux 
On Thu, May 17, 2018 at 04:41:35PM +0100, Daniel Stone wrote:
> On 17 May 2018 at 16:26, Russell King - ARM Linux  
> wrote:
> > On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote:
> >> On 30 March 2018 at 15:11, 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.
> >>
> >> 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.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

2018-05-18 Thread Russell King - ARM Linux 
On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote:
> Hi Russell,
> 
> On 30 March 2018 at 15:11, 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.
> 
> 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's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

2018-05-17 Thread Daniel Stone 
On 17 May 2018 at 16:26, Russell King - ARM Linux  wrote:
> On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote:
>> On 30 March 2018 at 15:11, 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.
>>
>> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

2018-05-17 Thread Thierry Reding 
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 
> Cc: Russell King 
> ---
>  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 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

2018-05-17 Thread Daniel Stone 
Hi Russell,

On 30 March 2018 at 15:11, 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.

Ping - have you had a chance to look at this?

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

2018-03-30 Thread Daniel Stone 
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 
Cc: Russell King 
---
 drivers/gpu/drm/armada/armada_fb.c | 23 ---
 drivers/gpu/drm/armada/armada_fb.h |  3 +--
 2 files changed, 5 insertions(+), 21 deletions(-)

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 
 #include 
+#include 
 #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(>fb);
-   drm_gem_object_put_unlocked(>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, >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;
 
drm_helper_mode_fill_fb_struct(dev, >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 *);
-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel