linux-next: manual merge of the drm-misc tree with the arm tree

linux-next: manual merge of the drm-misc tree with the arm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/sti/sti_drv.c

between commit:

  062993b15e8e ("drm: convert DT component matching to component_match_add_release()")

from the arm tree and commit:

  84601dbdea36 ("drm: sti: rework init sequence")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/sti/sti_drv.c
index 8abb57a94651,96bd3d08b2d4..000000000000
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@@ -340,14 -320,79 +320,84 @@@ static int compare_of(struct device *de
  	return dev->of_node == data;
  }
  
 +static void release_of(struct device *dev, void *data)
 +{
 +	of_node_put(data);
 +}
 +
+ static int sti_init(struct drm_device *ddev)
+ {
+ 	struct sti_private *private;
+ 
+ 	private = kzalloc(sizeof(*private), GFP_KERNEL);
+ 	if (!private)
+ 		return -ENOMEM;
+ 
+ 	ddev->dev_private = (void *)private;
+ 	dev_set_drvdata(ddev->dev, ddev);
+ 	private->drm_dev = ddev;
+ 
+ 	mutex_init(&private->commit.lock);
+ 	INIT_WORK(&private->commit.work, sti_atomic_work);
+ 
+ 	drm_mode_config_init(ddev);
+ 
+ 	sti_mode_config_init(ddev);
+ 
+ 	drm_kms_helper_poll_init(ddev);
+ 
+ 	return 0;
+ }
+ 
+ static void sti_cleanup(struct drm_device *ddev)
+ {
+ 	struct sti_private *private = ddev->dev_private;
+ 
+ 	if (private->fbdev) {
+ 		drm_fbdev_cma_fini(private->fbdev);
+ 		private->fbdev = NULL;
+ 	}
+ 
+ 	drm_kms_helper_poll_fini(ddev);
+ 	drm_vblank_cleanup(ddev);
+ 	kfree(private);
+ 	ddev->dev_private = NULL;
+ }
+ 
  static int sti_bind(struct device *dev)
  {
- 	return drm_platform_init(&sti_driver, to_platform_device(dev));
+ 	struct drm_device *ddev;
+ 	int ret;
+ 
+ 	ddev = drm_dev_alloc(&sti_driver, dev);
+ 	if (!ddev)
+ 		return -ENOMEM;
+ 
+ 	ddev->platformdev = to_platform_device(dev);
+ 
+ 	ret = sti_init(ddev);
+ 	if (ret)
+ 		goto err_drm_dev_unref;
+ 
+ 	ret = component_bind_all(ddev->dev, ddev);
+ 	if (ret)
+ 		goto err_cleanup;
+ 
+ 	ret = drm_dev_register(ddev, 0);
+ 	if (ret)
+ 		goto err_register;
+ 
+ 	drm_mode_config_reset(ddev);
+ 
+ 	return 0;
+ 
+ err_register:
+ 	drm_mode_config_cleanup(ddev);
+ err_cleanup:
+ 	sti_cleanup(ddev);
+ err_drm_dev_unref:
+ 	drm_dev_unref(ddev);
+ 	return ret;
  }
  
  static void sti_unbind(struct device *dev)

Re: linux-next: manual merge of the drm-misc tree with the arm tree

[Daniel Vetter]

On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
>   drivers/gpu/drm/sti/sti_drv.c
>
> between commit:
>
>   062993b15e8e ("drm: convert DT component matching to component_match_add_release()")

Why did that one end up in the arm tree? Should it go in through
drm-misc instead?
-Daniel

> from the arm tree and commit:
>
>   84601dbdea36 ("drm: sti: rework init sequence")
>
> from the drm-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/sti/sti_drv.c
> index 8abb57a94651,96bd3d08b2d4..000000000000
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@@ -340,14 -320,79 +320,84 @@@ static int compare_of(struct device *de
>         return dev->of_node == data;
>   }
>
>  +static void release_of(struct device *dev, void *data)
>  +{
>  +      of_node_put(data);
>  +}
>  +
> + static int sti_init(struct drm_device *ddev)
> + {
> +       struct sti_private *private;
> +
> +       private = kzalloc(sizeof(*private), GFP_KERNEL);
> +       if (!private)
> +               return -ENOMEM;
> +
> +       ddev->dev_private = (void *)private;
> +       dev_set_drvdata(ddev->dev, ddev);
> +       private->drm_dev = ddev;
> +
> +       mutex_init(&private->commit.lock);
> +       INIT_WORK(&private->commit.work, sti_atomic_work);
> +
> +       drm_mode_config_init(ddev);
> +
> +       sti_mode_config_init(ddev);
> +
> +       drm_kms_helper_poll_init(ddev);
> +
> +       return 0;
> + }
> +
> + static void sti_cleanup(struct drm_device *ddev)
> + {
> +       struct sti_private *private = ddev->dev_private;
> +
> +       if (private->fbdev) {
> +               drm_fbdev_cma_fini(private->fbdev);
> +               private->fbdev = NULL;
> +       }
> +
> +       drm_kms_helper_poll_fini(ddev);
> +       drm_vblank_cleanup(ddev);
> +       kfree(private);
> +       ddev->dev_private = NULL;
> + }
> +
>   static int sti_bind(struct device *dev)
>   {
> -       return drm_platform_init(&sti_driver, to_platform_device(dev));
> +       struct drm_device *ddev;
> +       int ret;
> +
> +       ddev = drm_dev_alloc(&sti_driver, dev);
> +       if (!ddev)
> +               return -ENOMEM;
> +
> +       ddev->platformdev = to_platform_device(dev);
> +
> +       ret = sti_init(ddev);
> +       if (ret)
> +               goto err_drm_dev_unref;
> +
> +       ret = component_bind_all(ddev->dev, ddev);
> +       if (ret)
> +               goto err_cleanup;
> +
> +       ret = drm_dev_register(ddev, 0);
> +       if (ret)
> +               goto err_register;
> +
> +       drm_mode_config_reset(ddev);
> +
> +       return 0;
> +
> + err_register:
> +       drm_mode_config_cleanup(ddev);
> + err_cleanup:
> +       sti_cleanup(ddev);
> + err_drm_dev_unref:
> +       drm_dev_unref(ddev);
> +       return ret;
>   }
>
>   static void sti_unbind(struct device *dev)



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

Re: linux-next: manual merge of the drm-misc tree with the arm tree

[Russell King]

On Wed, Jun 22, 2016 at 09:31:18AM +0200, Daniel Vetter wrote:
> On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi all,
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> >   drivers/gpu/drm/sti/sti_drv.c
> >
> > between commit:
> >
> >   062993b15e8e ("drm: convert DT component matching to component_match_add_release()")
> 
> Why did that one end up in the arm tree? Should it go in through
> drm-misc instead?

Mine is part of a three part patch series which is part of the component
helper updates (which I'm the author and maintainer of).

Then someone came up with an alternative way of some of part of it.

You can't merge the above DRM part, because that means you also need to
merge patch 1, which is core component stuff.

-- 
Russell King
ARM architecture Linux Kernel maintainer

Re: linux-next: manual merge of the drm-misc tree with the arm tree

[Daniel Vetter]

On Wed, Jun 22, 2016 at 09:21:11AM +0100, Russell King wrote:
> On Wed, Jun 22, 2016 at 09:31:18AM +0200, Daniel Vetter wrote:
> > On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > >
> > >   drivers/gpu/drm/sti/sti_drv.c
> > >
> > > between commit:
> > >
> > >   062993b15e8e ("drm: convert DT component matching to component_match_add_release()")
> > 
> > Why did that one end up in the arm tree? Should it go in through
> > drm-misc instead?
> 
> Mine is part of a three part patch series which is part of the component
> helper updates (which I'm the author and maintainer of).
> 
> Then someone came up with an alternative way of some of part of it.
> 
> You can't merge the above DRM part, because that means you also need to
> merge patch 1, which is core component stuff.

Makes sense, but generally in that case I ask Dave for an explicit ack for
merging through another tree to avoid confusion. Lack of that is why I
asked.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: linux-next: manual merge of the drm-misc tree with the arm tree

[Russell King]

On Wed, Jun 22, 2016 at 10:23:36AM +0200, Daniel Vetter wrote:
> On Wed, Jun 22, 2016 at 09:21:11AM +0100, Russell King wrote:
> > On Wed, Jun 22, 2016 at 09:31:18AM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > > >
> > > >   drivers/gpu/drm/sti/sti_drv.c
> > > >
> > > > between commit:
> > > >
> > > >   062993b15e8e ("drm: convert DT component matching to component_match_add_release()")
> > > 
> > > Why did that one end up in the arm tree? Should it go in through
> > > drm-misc instead?
> > 
> > Mine is part of a three part patch series which is part of the component
> > helper updates (which I'm the author and maintainer of).
> > 
> > Then someone came up with an alternative way of some of part of it.
> > 
> > You can't merge the above DRM part, because that means you also need to
> > merge patch 1, which is core component stuff.
> 
> Makes sense, but generally in that case I ask Dave for an explicit ack for
> merging through another tree to avoid confusion. Lack of that is why I
> asked.

It got posted to the appropriate mailing lists with CCs, including David.
Just three people responded.

One of the responses was that people didn't like the duplication.  I
posted v2 the same day, the DT people didn't like the file location, so
I went back to v1.  That then sparked someone to start working _against_
me, cleaning up the existing duplication, and acknowledging that it'll
cause _me_ problems.

So, as it was done maliciously and intentionally to give these porblems,
I'm not budging on this.  Sorry.

There are times when working on the kernel is not very nice.  This is one
of them.

-- 
Russell King
ARM architecture Linux Kernel maintainer

Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the arm tree

[Daniel Vetter]

On Wed, Jun 22, 2016 at 10:43 AM, Russell King <rmk@armlinux.org.uk> wrote:
> On Wed, Jun 22, 2016 at 10:23:36AM +0200, Daniel Vetter wrote:
>> On Wed, Jun 22, 2016 at 09:21:11AM +0100, Russell King wrote:
>> > On Wed, Jun 22, 2016 at 09:31:18AM +0200, Daniel Vetter wrote:
>> > > On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > > > Hi all,
>> > > >
>> > > > Today's linux-next merge of the drm-misc tree got a conflict in:
>> > > >
>> > > >   drivers/gpu/drm/sti/sti_drv.c
>> > > >
>> > > > between commit:
>> > > >
>> > > >   062993b15e8e ("drm: convert DT component matching to component_match_add_release()")
>> > >
>> > > Why did that one end up in the arm tree? Should it go in through
>> > > drm-misc instead?
>> >
>> > Mine is part of a three part patch series which is part of the component
>> > helper updates (which I'm the author and maintainer of).
>> >
>> > Then someone came up with an alternative way of some of part of it.
>> >
>> > You can't merge the above DRM part, because that means you also need to
>> > merge patch 1, which is core component stuff.
>>
>> Makes sense, but generally in that case I ask Dave for an explicit ack for
>> merging through another tree to avoid confusion. Lack of that is why I
>> asked.
>
> It got posted to the appropriate mailing lists with CCs, including David.
> Just three people responded.
>
> One of the responses was that people didn't like the duplication.  I
> posted v2 the same day, the DT people didn't like the file location, so
> I went back to v1.  That then sparked someone to start working _against_
> me, cleaning up the existing duplication, and acknowledging that it'll
> cause _me_ problems.
>
> So, as it was done maliciously and intentionally to give these porblems,
> I'm not budging on this.  Sorry.
>
> There are times when working on the kernel is not very nice.  This is one
> of them.

Please don't jump the gun right away, I just wanted to figure out
what's going on and make sure collaboration and coordination is
working smoothly. At least from what I could see that discussion
didn't happen on dri-devel (or I missed it), so totally didn't know
what's up.

Also, please don't just charge ahead, at least here in the drm
subsystem we try hard to work together and be friendly, and in my
experience there's no isssue at all in getting acks for cases like
this. And really, the conflict with drm-misc seems to be trivial.

But immediately building a castle and marking an aggressive defensive
stance ("I'm not budging on this.") isn't helping anyone. Indeed I
think it's actively harming collaboration and our community,
especially in this case here where I think there wasn't even a problem
to begin with (on the drm side at least, like I said didn't know about
dt). I don't think this is acceptable conduct, next time around please
calm down first before replying in anger. I, and the drm community
here, would really appreciate this.

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

linux-next: manual merge of the drm-misc tree with the arm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/rockchip/rockchip_drm_drv.c

between commit:

  062993b15e8e ("drm: convert DT component matching to component_match_add_release()")

from the arm tree and commit:

  6d5fa28c13b9 ("gpu: drm: rockchip_drm_drv: add missing of_node_put after calling of_parse_phandle")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 7fd20c0e1fc8,f0bd1ee8b128..000000000000
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@@ -438,9 -433,8 +438,10 @@@ static int rockchip_drm_platform_probe(
  			is_support_iommu = false;
  		}
  
+ 		of_node_put(iommu);
 -		component_match_add(dev, &match, compare_of, port->parent);
 +		of_node_get(port->parent);
 +		component_match_add_release(dev, &match, release_of,
 +					    compare_of, port->parent);
  		of_node_put(port);
  	}