linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
@ 2022-04-13 23:47 Stephen Rothwell
  2022-04-14  6:33 ` Christian König
  2022-04-26  1:48 ` Stephen Rothwell
  0 siblings, 2 replies; 14+ messages in thread
From: Stephen Rothwell @ 2022-04-13 23:47 UTC (permalink / raw)
  To: Daniel Vetter, Intel Graphics, DRI
  Cc: Christian König, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  drivers/gpu/drm/radeon/radeon_sync.c

between commit:

  022074918042 ("drm/radeon: fix logic inversion in radeon_sync_resv")

from the drm-misc-fixes tree and commit:

  7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4")

from the drm-misc tree.

I fixed it up (I just used the latter version) 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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
  2022-04-13 23:47 linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree Stephen Rothwell
@ 2022-04-14  6:33 ` Christian König
  2022-04-26  1:48 ` Stephen Rothwell
  1 sibling, 0 replies; 14+ messages in thread
From: Christian König @ 2022-04-14  6:33 UTC (permalink / raw)
  To: Stephen Rothwell, Daniel Vetter, Intel Graphics, DRI
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

Am 14.04.22 um 01:47 schrieb Stephen Rothwell:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
>    drivers/gpu/drm/radeon/radeon_sync.c
>
> between commit:
>
>    022074918042 ("drm/radeon: fix logic inversion in radeon_sync_resv")
>
> from the drm-misc-fixes tree and commit:
>
>    7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4")
>
> from the drm-misc tree.
>
> I fixed it up (I just used the latter version) and can carry the fix as
> necessary.

I still need to double check the result in linux-next, but that doesn't 
sounds right.

The missing "!" needs to be carried into the new function call.

drm-tip should have the right solution to this merge conflict.

Thanks,
Christian.

> 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.
>


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
  2022-04-13 23:47 linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree Stephen Rothwell
  2022-04-14  6:33 ` Christian König
@ 2022-04-26  1:48 ` Stephen Rothwell
  1 sibling, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2022-04-26  1:48 UTC (permalink / raw)
  To: Dave Airlie
  Cc: Daniel Vetter, Intel Graphics, DRI, Christian König,
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Thu, 14 Apr 2022 09:47:15 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/radeon/radeon_sync.c
> 
> between commit:
> 
>   022074918042 ("drm/radeon: fix logic inversion in radeon_sync_resv")
> 
> from the drm-misc-fixes tree and commit:
> 
>   7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4")
> 
> from the drm-misc tree.
> 
> I fixed it up (I just used the latter version) 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.

This is now a conflict between the drm tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
@ 2023-01-27  2:28 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2023-01-27  2:28 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Intel Graphics, DRI, Javier Martinez Canillas,
	Linux Kernel Mailing List, Linux Next Mailing List,
	Thomas Zimmermann

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

Hi all,

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

  drivers/gpu/drm/drm_fbdev_generic.c

between commits:

  cc88ad784e42 ("drm/fb-helper: Check fb_deferred_io_init() return value")
  d6591da5f3ff ("drm/fb-helper: Use a per-driver FB deferred I/O handler")

from the drm-misc-fixes tree and commit:

  6ca80b9e5cc0 ("drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info'")

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/drm_fbdev_generic.c
index bd1f8f28297c,43f94aa9e015..000000000000
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@@ -200,31 -189,25 +184,31 @@@ static int drm_fbdev_fb_probe(struct dr
  	fb_helper->fb = buffer->fb;
  	fb = buffer->fb;
  
- 	fbi = drm_fb_helper_alloc_info(fb_helper);
- 	if (IS_ERR(fbi))
- 		return PTR_ERR(fbi);
+ 	info = drm_fb_helper_alloc_info(fb_helper);
+ 	if (IS_ERR(info))
+ 		return PTR_ERR(info);
  
- 	fbi->fbops = &drm_fbdev_fb_ops;
- 	fbi->screen_size = sizes->surface_height * fb->pitches[0];
- 	fbi->fix.smem_len = fbi->screen_size;
- 	fbi->flags = FBINFO_DEFAULT;
+ 	info->fbops = &drm_fbdev_fb_ops;
+ 	info->screen_size = sizes->surface_height * fb->pitches[0];
+ 	info->fix.smem_len = info->screen_size;
+ 	info->flags = FBINFO_DEFAULT;
  
- 	drm_fb_helper_fill_info(fbi, fb_helper, sizes);
+ 	drm_fb_helper_fill_info(info, fb_helper, sizes);
  
  	if (drm_fbdev_use_shadow_fb(fb_helper)) {
- 		fbi->screen_buffer = vzalloc(fbi->screen_size);
- 		if (!fbi->screen_buffer)
+ 		info->screen_buffer = vzalloc(info->screen_size);
+ 		if (!info->screen_buffer)
  			return -ENOMEM;
- 		fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
+ 		info->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
  
 -		info->fbdefio = &drm_fbdev_defio;
 -		fb_deferred_io_init(info);
 +		/* Set a default deferred I/O handler */
 +		fb_helper->fbdefio.delay = HZ / 20;
 +		fb_helper->fbdefio.deferred_io = drm_fb_helper_deferred_io;
 +
- 		fbi->fbdefio = &fb_helper->fbdefio;
- 		ret = fb_deferred_io_init(fbi);
++		info->fbdefio = &fb_helper->fbdefio;
++		ret = fb_deferred_io_init(info);
 +		if (ret)
 +			return ret;
  	} else {
  		/* buffer is mapped for HW framebuffer */
  		ret = drm_client_buffer_vmap(fb_helper->buffer, &map);

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
  2022-11-16  0:25 ` Stephen Rothwell
@ 2022-11-16 12:13   ` Christian König
  0 siblings, 0 replies; 14+ messages in thread
From: Christian König @ 2022-11-16 12:13 UTC (permalink / raw)
  To: Stephen Rothwell, Daniel Vetter, Intel Graphics, DRI
  Cc: Linux Kernel Mailing List, Linux Next Mailing List



Am 16.11.22 um 01:25 schrieb Stephen Rothwell:
> Hi all,
>
> On Wed, 16 Nov 2022 10:47:52 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Today's linux-next merge of the drm-misc tree got a conflict in:
>>
>>    drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>
>> between commit:
>>
>>    eca13f3c67b6 ("drm/amdgpu: use the last IB as gang leader v2")
>>
>> from the drm-misc-fixes tree and commit:
>>
>>    1728baa7e4e6 ("drm/amdgpu: use scheduler dependencies for CS")
>>
>> 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/amd/amdgpu/amdgpu_cs.c
>> index de5cb056c9ad,0528c2b1db6e..000000000000
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> @@@ -1197,10 -1201,7 +1203,10 @@@ static int amdgpu_cs_sync_rings(struct
>>    	}
>>    
>>    	for (i = 0; i < p->gang_size; ++i) {
>>   +		if (p->jobs[i] == leader)
>>   +			continue;
>>   +
>> - 		r = amdgpu_sync_clone(&leader->sync, &p->jobs[i]->sync);
>> + 		r = amdgpu_sync_push_to_job(&p->sync, p->jobs[i]);
>>    		if (r)
>>    			return r;
>>    	}
>> @@@ -1241,14 -1243,11 +1247,14 @@@ static int amdgpu_cs_submit(struct amdg
>>    	for (i = 0; i < p->gang_size; ++i)
>>    		drm_sched_job_arm(&p->jobs[i]->base);
>>    
>>   -	for (i = 0; i < (p->gang_size - 1); ++i) {
>>   +	for (i = 0; i < p->gang_size; ++i) {
>>    		struct dma_fence *fence;
>>    
>>   +		if (p->jobs[i] == leader)
>>   +			continue;
>>   +
>>    		fence = &p->jobs[i]->base.s_fence->scheduled;
>> - 		r = amdgpu_sync_fence(&leader->sync, fence);
>> + 		r = drm_sched_job_add_dependency(&leader->base, fence);
>>    		if (r)
>>    			goto error_cleanup;
>>    	}
> Note that I had to keep the declaration of "leader" in amdgpu_cs_sync_rings().

This and all your other merge resolutions look good to me.

And sorry for the noise, drm-tip somehow doesn't seem to work any more 
and we had a lot of conflicting patches going in through -fixes and -next.

Regards,
Christian.

>


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
  2022-11-15 23:47 Stephen Rothwell
@ 2022-11-16  0:25 ` Stephen Rothwell
  2022-11-16 12:13   ` Christian König
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2022-11-16  0:25 UTC (permalink / raw)
  To: Daniel Vetter, Intel Graphics, DRI
  Cc: Christian König, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Wed, 16 Nov 2022 10:47:52 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> 
> between commit:
> 
>   eca13f3c67b6 ("drm/amdgpu: use the last IB as gang leader v2")
> 
> from the drm-misc-fixes tree and commit:
> 
>   1728baa7e4e6 ("drm/amdgpu: use scheduler dependencies for CS")
> 
> 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/amd/amdgpu/amdgpu_cs.c
> index de5cb056c9ad,0528c2b1db6e..000000000000
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@@ -1197,10 -1201,7 +1203,10 @@@ static int amdgpu_cs_sync_rings(struct 
>   	}
>   
>   	for (i = 0; i < p->gang_size; ++i) {
>  +		if (p->jobs[i] == leader)
>  +			continue;
>  +
> - 		r = amdgpu_sync_clone(&leader->sync, &p->jobs[i]->sync);
> + 		r = amdgpu_sync_push_to_job(&p->sync, p->jobs[i]);
>   		if (r)
>   			return r;
>   	}
> @@@ -1241,14 -1243,11 +1247,14 @@@ static int amdgpu_cs_submit(struct amdg
>   	for (i = 0; i < p->gang_size; ++i)
>   		drm_sched_job_arm(&p->jobs[i]->base);
>   
>  -	for (i = 0; i < (p->gang_size - 1); ++i) {
>  +	for (i = 0; i < p->gang_size; ++i) {
>   		struct dma_fence *fence;
>   
>  +		if (p->jobs[i] == leader)
>  +			continue;
>  +
>   		fence = &p->jobs[i]->base.s_fence->scheduled;
> - 		r = amdgpu_sync_fence(&leader->sync, fence);
> + 		r = drm_sched_job_add_dependency(&leader->base, fence);
>   		if (r)
>   			goto error_cleanup;
>   	}

Note that I had to keep the declaration of "leader" in amdgpu_cs_sync_rings().

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
@ 2022-11-15 23:47 Stephen Rothwell
  2022-11-16  0:25 ` Stephen Rothwell
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2022-11-15 23:47 UTC (permalink / raw)
  To: Daniel Vetter, Intel Graphics, DRI
  Cc: Christian König, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c

between commit:

  eca13f3c67b6 ("drm/amdgpu: use the last IB as gang leader v2")

from the drm-misc-fixes tree and commit:

  1728baa7e4e6 ("drm/amdgpu: use scheduler dependencies for CS")

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/amd/amdgpu/amdgpu_cs.c
index de5cb056c9ad,0528c2b1db6e..000000000000
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@@ -1197,10 -1201,7 +1203,10 @@@ static int amdgpu_cs_sync_rings(struct 
  	}
  
  	for (i = 0; i < p->gang_size; ++i) {
 +		if (p->jobs[i] == leader)
 +			continue;
 +
- 		r = amdgpu_sync_clone(&leader->sync, &p->jobs[i]->sync);
+ 		r = amdgpu_sync_push_to_job(&p->sync, p->jobs[i]);
  		if (r)
  			return r;
  	}
@@@ -1241,14 -1243,11 +1247,14 @@@ static int amdgpu_cs_submit(struct amdg
  	for (i = 0; i < p->gang_size; ++i)
  		drm_sched_job_arm(&p->jobs[i]->base);
  
 -	for (i = 0; i < (p->gang_size - 1); ++i) {
 +	for (i = 0; i < p->gang_size; ++i) {
  		struct dma_fence *fence;
  
 +		if (p->jobs[i] == leader)
 +			continue;
 +
  		fence = &p->jobs[i]->base.s_fence->scheduled;
- 		r = amdgpu_sync_fence(&leader->sync, fence);
+ 		r = drm_sched_job_add_dependency(&leader->base, fence);
  		if (r)
  			goto error_cleanup;
  	}

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
@ 2020-10-29  1:18 Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2020-10-29  1:18 UTC (permalink / raw)
  To: Daniel Vetter, Intel Graphics, DRI
  Cc: Daniel Vetter, Linux Kernel Mailing List,
	Linux Next Mailing List, Thomas Zimmermann

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

Hi all,

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

  drivers/gpu/drm/drm_gem.c

between commit:

  f49a51bfdc8e ("drm/shme-helpers: Fix dma_buf_mmap forwarding bug")

from the drm-misc-fixes tree and commit:

  d693def4fd1c ("drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver")

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/drm_gem.c
index 69c2c079d803,1da67d34e55d..000000000000
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@@ -1085,9 -1076,7 +1076,9 @@@ int drm_gem_mmap_obj(struct drm_gem_obj
  	 */
  	drm_gem_object_get(obj);
  
 +	vma->vm_private_data = obj;
 +
- 	if (obj->funcs && obj->funcs->mmap) {
+ 	if (obj->funcs->mmap) {
  		ret = obj->funcs->mmap(obj, vma);
  		if (ret) {
  			drm_gem_object_put(obj);

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
  2020-04-23  3:17   ` Stephen Rothwell
@ 2020-05-15 11:32     ` Tomi Valkeinen
  0 siblings, 0 replies; 14+ messages in thread
From: Tomi Valkeinen @ 2020-05-15 11:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Dave Airlie, Daniel Vetter, Intel Graphics, DRI,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Thomas Zimmermann

Hi Stephen,

On 23/04/2020 06:17, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 21 Apr 2020 09:10:25 +0300 Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>
>> On 21/04/2020 04:52, Stephen Rothwell wrote:
>>>
>>> Today's linux-next merge of the drm-misc tree got a conflict in:he drm-misc tree with the drm-misc-fixes tree
>>>
>>>     drivers/gpu/drm/tidss/tidss_encoder.c
>>>
>>> between commit:
>>>
>>>     9da67433f64e ("drm/tidss: fix crash related to accessing freed memory")
>>>
>>> from the drm-misc-fixes tree and commit:
>>>
>>>     b28ad7deb2f2 ("drm/tidss: Use simple encoder")
>>>
>>> from the drm-misc tree.
>>>
>>> I fixed it up (I just used the latter version of this file) and can
>>
>> We need to use "drm/tidss: fix crash related to accessing freed memory" version.
>>
>>> 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.
>>
>> I have fixed this with drm-misc's dim tool, so I presume the conflict goes away when drm-misc-fixes
>> is merged to drm-fixes, and drm-fixes is then at some point merged to drm-misc-next.
>>
>> It was a bit bad timing with the "drm/tidss: Use simple encoder", which removes the plumbing I
>> needed to implement the fix. So I effectively revert the "drm/tidss: Use simple encoder".
>>
>>    Tomi
>>
> 
> This is now a conflict between the drm and drm-misc-fixes trees.

The fix ("drm/tidss: fix crash related to accessing freed memory") is in v5.7-rc3, and the conflicting change ("drm/tidss: Use simple encoder") in drm-next.

The conflict resolution in linux-next drops the fix and take the change from drm-next, which causes crash on module removal.

Here's the diff I made on top of linux-next to fix it. Essentially dropping the simple-encoder change, and reapplying the fix. This should be fixed in drm-next when Dave next time pulls in Linus' branch.

diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c b/drivers/gpu/drm/tidss/tidss_encoder.c
index 4c0558286f5e..e624cdcbb567 100644
--- a/drivers/gpu/drm/tidss/tidss_encoder.c
+++ b/drivers/gpu/drm/tidss/tidss_encoder.c
@@ -56,25 +56,38 @@ static int tidss_encoder_atomic_check(struct drm_encoder *encoder,
 	return 0;
 }
 
+static void tidss_encoder_destroy(struct drm_encoder *encoder)
+{
+	drm_encoder_cleanup(encoder);
+	kfree(encoder);
+}
+
 static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
 	.atomic_check = tidss_encoder_atomic_check,
 };
 
+static const struct drm_encoder_funcs encoder_funcs = {
+	.destroy = tidss_encoder_destroy,
+};
+
 struct drm_encoder *tidss_encoder_create(struct tidss_device *tidss,
 					 u32 encoder_type, u32 possible_crtcs)
 {
 	struct drm_encoder *enc;
 	int ret;
 
-	enc = devm_kzalloc(tidss->dev, sizeof(*enc), GFP_KERNEL);
+	enc = kzalloc(sizeof(*enc), GFP_KERNEL);
 	if (!enc)
 		return ERR_PTR(-ENOMEM);
 
 	enc->possible_crtcs = possible_crtcs;
 
-	ret = drm_simple_encoder_init(&tidss->ddev, enc, encoder_type);
-	if (ret < 0)
+	ret = drm_encoder_init(&tidss->ddev, enc, &encoder_funcs,
+			       encoder_type, NULL);
+	if (ret < 0) {
+		kfree(enc);
 		return ERR_PTR(ret);
+	}
 
 	drm_encoder_helper_add(enc, &encoder_helper_funcs);
 


 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
  2020-04-21  6:10 ` Tomi Valkeinen
@ 2020-04-23  3:17   ` Stephen Rothwell
  2020-05-15 11:32     ` Tomi Valkeinen
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2020-04-23  3:17 UTC (permalink / raw)
  To: Dave Airlie
  Cc: Tomi Valkeinen, Daniel Vetter, Intel Graphics, DRI,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Thomas Zimmermann

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

Hi all,

On Tue, 21 Apr 2020 09:10:25 +0300 Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> On 21/04/2020 04:52, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the drm-misc tree got a conflict in:he drm-misc tree with the drm-misc-fixes tree
> > 
> >    drivers/gpu/drm/tidss/tidss_encoder.c
> > 
> > between commit:
> > 
> >    9da67433f64e ("drm/tidss: fix crash related to accessing freed memory")
> > 
> > from the drm-misc-fixes tree and commit:
> > 
> >    b28ad7deb2f2 ("drm/tidss: Use simple encoder")
> > 
> > from the drm-misc tree.
> > 
> > I fixed it up (I just used the latter version of this file) and can  
> 
> We need to use "drm/tidss: fix crash related to accessing freed memory" version.
> 
> > 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.  
> 
> I have fixed this with drm-misc's dim tool, so I presume the conflict goes away when drm-misc-fixes 
> is merged to drm-fixes, and drm-fixes is then at some point merged to drm-misc-next.
> 
> It was a bit bad timing with the "drm/tidss: Use simple encoder", which removes the plumbing I 
> needed to implement the fix. So I effectively revert the "drm/tidss: Use simple encoder".
> 
>   Tomi
> 

This is now a conflict between the drm and drm-misc-fixes trees.

-- 
Cheers,
Stephen Rothwell

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
  2020-04-21  1:52 Stephen Rothwell
@ 2020-04-21  6:10 ` Tomi Valkeinen
  2020-04-23  3:17   ` Stephen Rothwell
  0 siblings, 1 reply; 14+ messages in thread
From: Tomi Valkeinen @ 2020-04-21  6:10 UTC (permalink / raw)
  To: Stephen Rothwell, Daniel Vetter, Intel Graphics, DRI
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Thomas Zimmermann

Hi,

On 21/04/2020 04:52, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drm-misc tree got a conflict in:he drm-misc tree with the drm-misc-fixes tree
> 
>    drivers/gpu/drm/tidss/tidss_encoder.c
> 
> between commit:
> 
>    9da67433f64e ("drm/tidss: fix crash related to accessing freed memory")
> 
> from the drm-misc-fixes tree and commit:
> 
>    b28ad7deb2f2 ("drm/tidss: Use simple encoder")
> 
> from the drm-misc tree.
> 
> I fixed it up (I just used the latter version of this file) and can

We need to use "drm/tidss: fix crash related to accessing freed memory" version.

> 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.

I have fixed this with drm-misc's dim tool, so I presume the conflict goes away when drm-misc-fixes 
is merged to drm-fixes, and drm-fixes is then at some point merged to drm-misc-next.

It was a bit bad timing with the "drm/tidss: Use simple encoder", which removes the plumbing I 
needed to implement the fix. So I effectively revert the "drm/tidss: Use simple encoder".

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
@ 2020-04-21  1:52 Stephen Rothwell
  2020-04-21  6:10 ` Tomi Valkeinen
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2020-04-21  1:52 UTC (permalink / raw)
  To: Daniel Vetter, Intel Graphics, DRI
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Tomi Valkeinen, Thomas Zimmermann

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

Hi all,

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

  drivers/gpu/drm/tidss/tidss_encoder.c

between commit:

  9da67433f64e ("drm/tidss: fix crash related to accessing freed memory")

from the drm-misc-fixes tree and commit:

  b28ad7deb2f2 ("drm/tidss: Use simple encoder")

from the drm-misc tree.

I fixed it up (I just used the latter version of this file) 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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
  2017-07-18  1:39 Stephen Rothwell
@ 2017-07-21  0:03 ` Stephen Rothwell
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Rothwell @ 2017-07-21  0:03 UTC (permalink / raw)
  To: Dave Airlie
  Cc: Daniel Vetter, Intel Graphics, DRI, Linux-Next Mailing List,
	Linux Kernel Mailing List, Boris Brezillon, Eric Anholt,
	Laurent Pinchart

Hi Dave,

The conflict below now exists between the drm-misc-fixes tree and the
drm tree.

On Tue, 18 Jul 2017 11:39:46 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/vc4/vc4_crtc.c
> 
> between commit:
> 
>   1ed134e6526b ("drm/vc4: Fix VBLANK handling in crtc->enable() path")
> 
> from the drm-misc-fixes tree and commit:
> 
>   0b20a0f8c3cb ("drm: Add old state pointer to CRTC .enable() helper function")
> 
> 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/vc4/vc4_crtc.c
> index a12cc7ea99b6,9e0c1500375c..000000000000
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@@ -518,37 -519,23 +519,51 @@@ static void vc4_crtc_atomic_disable(str
>   	WARN_ON_ONCE((HVS_READ(SCALER_DISPSTATX(chan)) &
>   		      (SCALER_DISPSTATX_FULL | SCALER_DISPSTATX_EMPTY)) !=
>   		     SCALER_DISPSTATX_EMPTY);
> + 
> + 	/*
> + 	 * Make sure we issue a vblank event after disabling the CRTC if
> + 	 * someone was waiting it.
> + 	 */
> + 	if (crtc->state->event) {
> + 		unsigned long flags;
> + 
> + 		spin_lock_irqsave(&dev->event_lock, flags);
> + 		drm_crtc_send_vblank_event(crtc, crtc->state->event);
> + 		crtc->state->event = NULL;
> + 		spin_unlock_irqrestore(&dev->event_lock, flags);
> + 	}
>   }
>   
>  +static void vc4_crtc_update_dlist(struct drm_crtc *crtc)
>  +{
>  +	struct drm_device *dev = crtc->dev;
>  +	struct vc4_dev *vc4 = to_vc4_dev(dev);
>  +	struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>  +	struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
>  +
>  +	if (crtc->state->event) {
>  +		unsigned long flags;
>  +
>  +		crtc->state->event->pipe = drm_crtc_index(crtc);
>  +
>  +		WARN_ON(drm_crtc_vblank_get(crtc) != 0);
>  +
>  +		spin_lock_irqsave(&dev->event_lock, flags);
>  +		vc4_crtc->event = crtc->state->event;
>  +		crtc->state->event = NULL;
>  +
>  +		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  +			  vc4_state->mm.start);
>  +
>  +		spin_unlock_irqrestore(&dev->event_lock, flags);
>  +	} else {
>  +		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  +			  vc4_state->mm.start);
>  +	}
>  +}
>  +
> - static void vc4_crtc_enable(struct drm_crtc *crtc)
> + static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
> + 				   struct drm_crtc_state *old_state)
>   {
>   	struct drm_device *dev = crtc->dev;
>   	struct vc4_dev *vc4 = to_vc4_dev(dev);
> @@@ -575,20 -556,22 +590,19 @@@
>   	/* Turn on the pixel valve, which will emit the vstart signal. */
>   	CRTC_WRITE(PV_V_CONTROL,
>   		   CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
>  -
>  -	/* Enable vblank irq handling after crtc is started. */
>  -	drm_crtc_vblank_on(crtc);
>   }
>   
> - static bool vc4_crtc_mode_fixup(struct drm_crtc *crtc,
> - 				const struct drm_display_mode *mode,
> - 				struct drm_display_mode *adjusted_mode)
> + static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
> + 						const struct drm_display_mode *mode)
>   {
>   	/* Do not allow doublescan modes from user space */
> - 	if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) {
> + 	if (mode->flags & DRM_MODE_FLAG_DBLSCAN) {
>   		DRM_DEBUG_KMS("[CRTC:%d] Doublescan mode rejected.\n",
>   			      crtc->base.id);
> - 		return false;
> + 		return MODE_NO_DBLESCAN;
>   	}
>   
> - 	return true;
> + 	return MODE_OK;
>   }
>   
>   static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
> @@@ -650,15 -634,25 +664,15 @@@ static void vc4_crtc_atomic_flush(struc
>   
>   	WARN_ON_ONCE(dlist_next - dlist_start != vc4_state->mm.size);
>   
>  -	if (crtc->state->event) {
>  -		unsigned long flags;
>  -
>  -		crtc->state->event->pipe = drm_crtc_index(crtc);
>  -
>  -		WARN_ON(drm_crtc_vblank_get(crtc) != 0);
>  -
>  -		spin_lock_irqsave(&dev->event_lock, flags);
>  -		vc4_crtc->event = crtc->state->event;
>  -		crtc->state->event = NULL;
>  -
>  -		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  -			  vc4_state->mm.start);
>  -
>  -		spin_unlock_irqrestore(&dev->event_lock, flags);
>  -	} else {
>  -		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
>  -			  vc4_state->mm.start);
>  -	}
>  +	/* Only update DISPLIST if the CRTC was already running and is not
>  +	 * being disabled.
> - 	 * vc4_crtc_enable() takes care of updating the dlist just after
> ++	 * vc4_crtc_atomic_enable() takes care of updating the dlist just after
>  +	 * re-enabling VBLANK interrupts and before enabling the engine.
>  +	 * If the CRTC is being disabled, there's no point in updating this
>  +	 * information.
>  +	 */
>  +	if (crtc->state->active && old_state->active)
>  +		vc4_crtc_update_dlist(crtc);
>   
>   	if (debug_dump_regs) {
>   		DRM_INFO("CRTC %d HVS after:\n", drm_crtc_index(crtc));



-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 14+ messages in thread

* linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
@ 2017-07-18  1:39 Stephen Rothwell
  2017-07-21  0:03 ` Stephen Rothwell
  0 siblings, 1 reply; 14+ messages in thread
From: Stephen Rothwell @ 2017-07-18  1:39 UTC (permalink / raw)
  To: Daniel Vetter, Intel Graphics, DRI
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Boris Brezillon, Eric Anholt, Laurent Pinchart

Hi all,

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

  drivers/gpu/drm/vc4/vc4_crtc.c

between commit:

  1ed134e6526b ("drm/vc4: Fix VBLANK handling in crtc->enable() path")

from the drm-misc-fixes tree and commit:

  0b20a0f8c3cb ("drm: Add old state pointer to CRTC .enable() helper function")

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/vc4/vc4_crtc.c
index a12cc7ea99b6,9e0c1500375c..000000000000
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@@ -518,37 -519,23 +519,51 @@@ static void vc4_crtc_atomic_disable(str
  	WARN_ON_ONCE((HVS_READ(SCALER_DISPSTATX(chan)) &
  		      (SCALER_DISPSTATX_FULL | SCALER_DISPSTATX_EMPTY)) !=
  		     SCALER_DISPSTATX_EMPTY);
+ 
+ 	/*
+ 	 * Make sure we issue a vblank event after disabling the CRTC if
+ 	 * someone was waiting it.
+ 	 */
+ 	if (crtc->state->event) {
+ 		unsigned long flags;
+ 
+ 		spin_lock_irqsave(&dev->event_lock, flags);
+ 		drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ 		crtc->state->event = NULL;
+ 		spin_unlock_irqrestore(&dev->event_lock, flags);
+ 	}
  }
  
 +static void vc4_crtc_update_dlist(struct drm_crtc *crtc)
 +{
 +	struct drm_device *dev = crtc->dev;
 +	struct vc4_dev *vc4 = to_vc4_dev(dev);
 +	struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
 +	struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
 +
 +	if (crtc->state->event) {
 +		unsigned long flags;
 +
 +		crtc->state->event->pipe = drm_crtc_index(crtc);
 +
 +		WARN_ON(drm_crtc_vblank_get(crtc) != 0);
 +
 +		spin_lock_irqsave(&dev->event_lock, flags);
 +		vc4_crtc->event = crtc->state->event;
 +		crtc->state->event = NULL;
 +
 +		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
 +			  vc4_state->mm.start);
 +
 +		spin_unlock_irqrestore(&dev->event_lock, flags);
 +	} else {
 +		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
 +			  vc4_state->mm.start);
 +	}
 +}
 +
- static void vc4_crtc_enable(struct drm_crtc *crtc)
+ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
+ 				   struct drm_crtc_state *old_state)
  {
  	struct drm_device *dev = crtc->dev;
  	struct vc4_dev *vc4 = to_vc4_dev(dev);
@@@ -575,20 -556,22 +590,19 @@@
  	/* Turn on the pixel valve, which will emit the vstart signal. */
  	CRTC_WRITE(PV_V_CONTROL,
  		   CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
 -
 -	/* Enable vblank irq handling after crtc is started. */
 -	drm_crtc_vblank_on(crtc);
  }
  
- static bool vc4_crtc_mode_fixup(struct drm_crtc *crtc,
- 				const struct drm_display_mode *mode,
- 				struct drm_display_mode *adjusted_mode)
+ static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
+ 						const struct drm_display_mode *mode)
  {
  	/* Do not allow doublescan modes from user space */
- 	if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) {
+ 	if (mode->flags & DRM_MODE_FLAG_DBLSCAN) {
  		DRM_DEBUG_KMS("[CRTC:%d] Doublescan mode rejected.\n",
  			      crtc->base.id);
- 		return false;
+ 		return MODE_NO_DBLESCAN;
  	}
  
- 	return true;
+ 	return MODE_OK;
  }
  
  static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
@@@ -650,15 -634,25 +664,15 @@@ static void vc4_crtc_atomic_flush(struc
  
  	WARN_ON_ONCE(dlist_next - dlist_start != vc4_state->mm.size);
  
 -	if (crtc->state->event) {
 -		unsigned long flags;
 -
 -		crtc->state->event->pipe = drm_crtc_index(crtc);
 -
 -		WARN_ON(drm_crtc_vblank_get(crtc) != 0);
 -
 -		spin_lock_irqsave(&dev->event_lock, flags);
 -		vc4_crtc->event = crtc->state->event;
 -		crtc->state->event = NULL;
 -
 -		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
 -			  vc4_state->mm.start);
 -
 -		spin_unlock_irqrestore(&dev->event_lock, flags);
 -	} else {
 -		HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
 -			  vc4_state->mm.start);
 -	}
 +	/* Only update DISPLIST if the CRTC was already running and is not
 +	 * being disabled.
- 	 * vc4_crtc_enable() takes care of updating the dlist just after
++	 * vc4_crtc_atomic_enable() takes care of updating the dlist just after
 +	 * re-enabling VBLANK interrupts and before enabling the engine.
 +	 * If the CRTC is being disabled, there's no point in updating this
 +	 * information.
 +	 */
 +	if (crtc->state->active && old_state->active)
 +		vc4_crtc_update_dlist(crtc);
  
  	if (debug_dump_regs) {
  		DRM_INFO("CRTC %d HVS after:\n", drm_crtc_index(crtc));

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2023-01-27  2:28 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-13 23:47 linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree Stephen Rothwell
2022-04-14  6:33 ` Christian König
2022-04-26  1:48 ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2023-01-27  2:28 Stephen Rothwell
2022-11-15 23:47 Stephen Rothwell
2022-11-16  0:25 ` Stephen Rothwell
2022-11-16 12:13   ` Christian König
2020-10-29  1:18 Stephen Rothwell
2020-04-21  1:52 Stephen Rothwell
2020-04-21  6:10 ` Tomi Valkeinen
2020-04-23  3:17   ` Stephen Rothwell
2020-05-15 11:32     ` Tomi Valkeinen
2017-07-18  1:39 Stephen Rothwell
2017-07-21  0:03 ` Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).