linux-next: build failure after merge of the mali-dp tree

linux-next: build failure after merge of the mali-dp tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4279 bytes --]

Hi Liviu,

After merging the mali-dp tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c: In function 'komeda_pipeline_obj_add':
drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:48:30: error: passing argument 1 of 'drm_atomic_private_obj_init' from incompatible pointer type [-Werror=incompatible-pointer-types]
  drm_atomic_private_obj_init(&pipe->obj, &st->obj,
                              ^~~~~~~~~~
In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
                 from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
                 from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
include/drm/drm_atomic.h:437:53: note: expected 'struct drm_device *' but argument is of type 'struct drm_private_obj *'
 void drm_atomic_private_obj_init(struct drm_device *dev,
                                  ~~~~~~~~~~~~~~~~~~~^~~
drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:48:42: error: passing argument 2 of 'drm_atomic_private_obj_init' from incompatible pointer type [-Werror=incompatible-pointer-types]
  drm_atomic_private_obj_init(&pipe->obj, &st->obj,
                                          ^~~~~~~~
In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
                 from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
                 from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
include/drm/drm_atomic.h:438:30: note: expected 'struct drm_private_obj *' but argument is of type 'struct drm_private_state *'
      struct drm_private_obj *obj,
      ~~~~~~~~~~~~~~~~~~~~~~~~^~~
drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:49:9: error: passing argument 3 of 'drm_atomic_private_obj_init' from incompatible pointer type [-Werror=incompatible-pointer-types]
         &komeda_pipeline_obj_funcs);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
                 from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
                 from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
include/drm/drm_atomic.h:439:32: note: expected 'struct drm_private_state *' but argument is of type 'const struct drm_private_state_funcs *'
      struct drm_private_state *state,
      ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:48:2: error: too few arguments to function 'drm_atomic_private_obj_init'
  drm_atomic_private_obj_init(&pipe->obj, &st->obj,
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
                 from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
                 from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
include/drm/drm_atomic.h:437:6: note: declared here
 void drm_atomic_private_obj_init(struct drm_device *dev,
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~

Caused by commit

  61f1c4a8ab75 ("drm/komeda: Attach komeda_dev to DRM-KMS")

interacting with commit

  b962a12050a3 ("drm/atomic: integrate modeset lock with private objects")

from the drm tree.

I have applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 15 Jan 2019 10:42:04 +1100
Subject: [PATCH] drm/komeda: merge fix for drm_atomic_private_obj_init() API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
index 9edfd6ab0c12..f1c9e3fefa86 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
@@ -45,7 +45,7 @@ static int komeda_pipeline_obj_add(struct komeda_kms_dev *kms,
 		return -ENOMEM;
 
 	st->pipe = pipe;
-	drm_atomic_private_obj_init(&pipe->obj, &st->obj,
+	drm_atomic_private_obj_init(&kms->base, &pipe->obj, &st->obj,
 				    &komeda_pipeline_obj_funcs);
 
 	return 0;
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the mali-dp tree

[Liviu Dudau]

On Tue, Jan 15, 2019 at 10:46:19AM +1100, Stephen Rothwell wrote:
> Hi Liviu,

Hi Stephen,

> 
> After merging the mali-dp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c: In function 'komeda_pipeline_obj_add':
> drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:48:30: error: passing argument 1 of 'drm_atomic_private_obj_init' from incompatible pointer type [-Werror=incompatible-pointer-types]
>   drm_atomic_private_obj_init(&pipe->obj, &st->obj,
>                               ^~~~~~~~~~
> In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
>                  from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
>                  from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
> include/drm/drm_atomic.h:437:53: note: expected 'struct drm_device *' but argument is of type 'struct drm_private_obj *'
>  void drm_atomic_private_obj_init(struct drm_device *dev,
>                                   ~~~~~~~~~~~~~~~~~~~^~~
> drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:48:42: error: passing argument 2 of 'drm_atomic_private_obj_init' from incompatible pointer type [-Werror=incompatible-pointer-types]
>   drm_atomic_private_obj_init(&pipe->obj, &st->obj,
>                                           ^~~~~~~~
> In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
>                  from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
>                  from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
> include/drm/drm_atomic.h:438:30: note: expected 'struct drm_private_obj *' but argument is of type 'struct drm_private_state *'
>       struct drm_private_obj *obj,
>       ~~~~~~~~~~~~~~~~~~~~~~~~^~~
> drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:49:9: error: passing argument 3 of 'drm_atomic_private_obj_init' from incompatible pointer type [-Werror=incompatible-pointer-types]
>          &komeda_pipeline_obj_funcs);
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
>                  from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
>                  from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
> include/drm/drm_atomic.h:439:32: note: expected 'struct drm_private_state *' but argument is of type 'const struct drm_private_state_funcs *'
>       struct drm_private_state *state,
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
> drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:48:2: error: too few arguments to function 'drm_atomic_private_obj_init'
>   drm_atomic_private_obj_init(&pipe->obj, &st->obj,
>   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
>                  from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
>                  from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
> include/drm/drm_atomic.h:437:6: note: declared here
>  void drm_atomic_private_obj_init(struct drm_device *dev,
>       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   61f1c4a8ab75 ("drm/komeda: Attach komeda_dev to DRM-KMS")
> 
> interacting with commit
> 
>   b962a12050a3 ("drm/atomic: integrate modeset lock with private objects")
> 
> from the drm tree.
> 
> I have applied the following merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 15 Jan 2019 10:42:04 +1100
> Subject: [PATCH] drm/komeda: merge fix for drm_atomic_private_obj_init() API change
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> index 9edfd6ab0c12..f1c9e3fefa86 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> @@ -45,7 +45,7 @@ static int komeda_pipeline_obj_add(struct komeda_kms_dev *kms,
>  		return -ENOMEM;
>  
>  	st->pipe = pipe;
> -	drm_atomic_private_obj_init(&pipe->obj, &st->obj,
> +	drm_atomic_private_obj_init(&kms->base, &pipe->obj, &st->obj,
>  				    &komeda_pipeline_obj_funcs);

That looks like the right fix, thank you for that! I will roll your
patch into my tree.

Best regards,
Liviu

>  
>  	return 0;
> -- 
> 2.20.1
> 
> -- 
> Cheers,
> Stephen Rothwell



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


-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: linux-next: build failure after merge of the mali-dp tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

Hi Liviu,

On Tue, 15 Jan 2019 10:12:19 +0000 Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>
> That looks like the right fix, thank you for that!

Thanks for your verification.

> I will roll your patch into my tree.

You can only do that when your tree is merged with the drm tree (and
it should be part of the merge resolution).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the mali-dp tree

[Liviu Dudau]

On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> Hi Liviu,
> 
> On Tue, 15 Jan 2019 10:12:19 +0000 Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> >
> > That looks like the right fix, thank you for that!
> 
> Thanks for your verification.
> 
> > I will roll your patch into my tree.
> 
> You can only do that when your tree is merged with the drm tree (and
> it should be part of the merge resolution).

I can also rebase on top of the latest drm-next tree, that should not be
a problem.

Best regards,
Liviu

> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: linux-next: build failure after merge of the mali-dp tree

[Daniel Vetter]

On Tue, Jan 15, 2019 at 10:51:02AM +0000, Liviu Dudau wrote:
> On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> > Hi Liviu,
> > 
> > On Tue, 15 Jan 2019 10:12:19 +0000 Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > >
> > > That looks like the right fix, thank you for that!
> > 
> > Thanks for your verification.
> > 
> > > I will roll your patch into my tree.
> > 
> > You can only do that when your tree is merged with the drm tree (and
> > it should be part of the merge resolution).
> 
> I can also rebase on top of the latest drm-next tree, that should not be
> a problem.

If you have a lot of patches already rebasing is kinda discouraged. There
might be other stuff that's conflicting and then making your entire tree
non-bisectable (maybe just on one platform that you missed in testing).

In that case just send out a pull for drm-next and include the merge
resolution in the pull request so Dave/I can double-check we did it right.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: linux-next: build failure after merge of the mali-dp tree

[Liviu Dudau]

On Tue, Jan 15, 2019 at 01:08:36PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 10:51:02AM +0000, Liviu Dudau wrote:
> > On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> > > Hi Liviu,
> > > 
> > > On Tue, 15 Jan 2019 10:12:19 +0000 Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > > >
> > > > That looks like the right fix, thank you for that!
> > > 
> > > Thanks for your verification.
> > > 
> > > > I will roll your patch into my tree.
> > > 
> > > You can only do that when your tree is merged with the drm tree (and
> > > it should be part of the merge resolution).
> > 
> > I can also rebase on top of the latest drm-next tree, that should not be
> > a problem.
> 
> If you have a lot of patches already rebasing is kinda discouraged. There
> might be other stuff that's conflicting and then making your entire tree
> non-bisectable (maybe just on one platform that you missed in testing).

My tree has always been "unstable", I have been rebasing it on top of
latest drm or drm-next in preparation for sending pull requests. I've hoped
that people don't depend on the linearity of my tree anyway and it hasn't
been an issue so far.

TBH, I should've based the latest update of my tree on drm-next anyway, I
just started at the time when it was at v5.0-rc1 so I thought it will not
matter.

Best regards,
Liviu

> 
> In that case just send out a pull for drm-next and include the merge
> resolution in the pull request so Dave/I can double-check we did it right.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: linux-next: build failure after merge of the mali-dp tree

[Daniel Vetter]

On Tue, Jan 15, 2019 at 1:23 PM Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>
> On Tue, Jan 15, 2019 at 01:08:36PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 10:51:02AM +0000, Liviu Dudau wrote:
> > > On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> > > > Hi Liviu,
> > > >
> > > > On Tue, 15 Jan 2019 10:12:19 +0000 Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > > > >
> > > > > That looks like the right fix, thank you for that!
> > > >
> > > > Thanks for your verification.
> > > >
> > > > > I will roll your patch into my tree.
> > > >
> > > > You can only do that when your tree is merged with the drm tree (and
> > > > it should be part of the merge resolution).
> > >
> > > I can also rebase on top of the latest drm-next tree, that should not be
> > > a problem.
> >
> > If you have a lot of patches already rebasing is kinda discouraged. There
> > might be other stuff that's conflicting and then making your entire tree
> > non-bisectable (maybe just on one platform that you missed in testing).
>
> My tree has always been "unstable", I have been rebasing it on top of
> latest drm or drm-next in preparation for sending pull requests. I've hoped
> that people don't depend on the linearity of my tree anyway and it hasn't
> been an issue so far.

"Don't unecessarily rebase" isn't only about screwing up people who
base their own stuff on your tree, it's also about invalidating
testing. E.g. if there's a silent conflict with latest drm-next, and
you rebase before sending out your pull request, but then don't notice
that new issue, then all these commit won't work in a bisect for a 2nd
issue.

But if you don't rebase, then only the merge commit will be broken
(until the bugfix was commit, which is hopefully not too long), and
all the commits on your branch still work.

So summary is that if you regularly rebase your pile of "ready for
linux-next" patches, then you're doing something wrong. And the bigger
your team (and hence the amount of work going on) the more wrong this
becomes. Ime you can rebase to squash in bugfixes with a bigger team
still, but rebasing to change the baseline stops being a good idea
pretty quickly.
-Daniel

> TBH, I should've based the latest update of my tree on drm-next anyway, I
> just started at the time when it was at v5.0-rc1 so I thought it will not
> matter.
>
> Best regards,
> Liviu
>
> >
> > In that case just send out a pull for drm-next and include the merge
> > resolution in the pull request so Dave/I can double-check we did it right.
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> --
> ====================
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---------------
>     ¯\_(ツ)_/¯
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

linux-next: build failure after merge of the mali-dp tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

Hi all,

After merging the mali-dp tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c:11:
drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.h:13:25: error: field 'base' has incomplete type
  struct drm_framebuffer base;
                         ^~~~

Caused by commit

  31849148cb41 ("drm/komeda: Add komeda_framebuffer")

I have used the mali-dp tree from next-20190111 for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]