| Message ID | 20190115104619.516be4b9@canb.auug.org.au (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | linux-next: build failure after merge of the mali-dp tree | expand |
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
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).
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
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
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
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
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;
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(-)