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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/omapdrm/dss/dsi.c

between commit:

  690911544275 ("drm/omap: dsi: fix unsigned expression compared with zero")

from the drm-misc-fixes tree and commit:

  bbd13d6a7b2e ("drm/omap: dsi: fix unreachable code in dsi_vc_send_short()")

from the drm tree.

I fixed it up (these do basically the same thing, so I used the former
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 --]

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

[Tomi Valkeinen]

On 18/03/2021 03:02, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drm tree got a conflict in:
> 
>    drivers/gpu/drm/omapdrm/dss/dsi.c
> 
> between commit:
> 
>    690911544275 ("drm/omap: dsi: fix unsigned expression compared with zero")
> 
> from the drm-misc-fixes tree and commit:
> 
>    bbd13d6a7b2e ("drm/omap: dsi: fix unreachable code in dsi_vc_send_short()")
> 
> from the drm tree.
> 
> I fixed it up (these do basically the same thing, so I used the former
> 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.
Yes, I messed that up. I accidentally merged a fix to drm-misc-fixes, 
but almost similar fix was already in drm-misc-next. Sorry about that.

  Tomi

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

[Geert Uytterhoeven]

Hi Stephen,

On Wed, Nov 22, 2023 at 1:29 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the drm tree got a conflict in:
>
>   drivers/accel/ivpu/ivpu_hw_37xx.c
>
> between commit:
>
>   3f7c0634926d ("accel/ivpu/37xx: Fix hangs related to MMIO reset")
>
> from the drm-misc-fixes tree and commits:
>
>   3de6d9597892 ("accel/ivpu: Pass D0i3 residency time to the VPU firmware")
>   cc19fedab8bd ("accel/ivpu/37xx: Print warning when VPUIP is not idle during power down")
>
> from the drm 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.

Thanks for your resolution!

> --- a/drivers/accel/ivpu/ivpu_hw_37xx.c
> +++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
> @@@ -720,14 -731,19 +733,14 @@@ static int ivpu_hw_37xx_power_down(stru
>   {
>         int ret = 0;
>
> -       if (!ivpu_hw_37xx_is_idle(vdev))
> -               ivpu_warn(vdev, "VPU not idle during power down\n");
> +       ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
>
> -       if (ivpu_hw_37xx_reset(vdev)) {
> -               ivpu_err(vdev, "Failed to reset VPU\n");
> -               ret = -EIO;
> +       if (!ivpu_hw_37xx_is_idle(vdev)) {
> +               ivpu_warn(vdev, "VPU not idle during power down\n");
> +               if (ivpu_hw_37xx_reset(vdev))
> +                       ivpu_warn(vdev, "Failed to reset the VPU\n");
>         }
>
>  -      if (ivpu_pll_disable(vdev)) {
>  -              ivpu_err(vdev, "Failed to disable PLL\n");
>  -              ret = -EIO;
>  -      }
>  -
>         if (ivpu_hw_37xx_d0i3_enable(vdev)) {
>                 ivpu_err(vdev, "Failed to enter D0I3\n");
>                 ret = -EIO;

I've just run into the same conflict, and I think you lost the split
into two if-statements in the last hunk of commit 3f7c0634926d
("accel/ivpu/37xx: Fix hangs related to MMIO reset")?

My resolution is:

--- a/drivers/accel/ivpu/ivpu_hw_37xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
@@@ -720,11 -731,16 +733,13 @@@ static int ivpu_hw_37xx_power_down(stru
  {
        int ret = 0;

+       ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
+
 -      if (!ivpu_hw_37xx_is_idle(vdev)) {
 +      if (!ivpu_hw_37xx_is_idle(vdev))
                ivpu_warn(vdev, "VPU not idle during power down\n");
 -              if (ivpu_hw_37xx_reset(vdev))
 -                      ivpu_warn(vdev, "Failed to reset the VPU\n");
 -      }

 -      if (ivpu_pll_disable(vdev)) {
 -              ivpu_err(vdev, "Failed to disable PLL\n");
 +      if (ivpu_hw_37xx_reset(vdev)) {
 +              ivpu_err(vdev, "Failed to reset VPU\n");
                ret = -EIO;
        }

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/accel/ivpu/ivpu_hw_37xx.c

between commit:

  3f7c0634926d ("accel/ivpu/37xx: Fix hangs related to MMIO reset")

from the drm-misc-fixes tree and commits:

  3de6d9597892 ("accel/ivpu: Pass D0i3 residency time to the VPU firmware")
  cc19fedab8bd ("accel/ivpu/37xx: Print warning when VPUIP is not idle during power down")

from the drm 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/accel/ivpu/ivpu_hw_37xx.c
index 4ccf1994b97a,4ab1f14cf360..000000000000
--- a/drivers/accel/ivpu/ivpu_hw_37xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
@@@ -720,14 -731,19 +733,14 @@@ static int ivpu_hw_37xx_power_down(stru
  {
  	int ret = 0;
  
- 	if (!ivpu_hw_37xx_is_idle(vdev))
- 		ivpu_warn(vdev, "VPU not idle during power down\n");
+ 	ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
  
- 	if (ivpu_hw_37xx_reset(vdev)) {
- 		ivpu_err(vdev, "Failed to reset VPU\n");
- 		ret = -EIO;
+ 	if (!ivpu_hw_37xx_is_idle(vdev)) {
+ 		ivpu_warn(vdev, "VPU not idle during power down\n");
+ 		if (ivpu_hw_37xx_reset(vdev))
+ 			ivpu_warn(vdev, "Failed to reset the VPU\n");
  	}
  
 -	if (ivpu_pll_disable(vdev)) {
 -		ivpu_err(vdev, "Failed to disable PLL\n");
 -		ret = -EIO;
 -	}
 -
  	if (ivpu_hw_37xx_d0i3_enable(vdev)) {
  		ivpu_err(vdev, "Failed to enter D0I3\n");
  		ret = -EIO;

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/accel/ivpu/ivpu_fw.c

between commit:

  645d694559ca ("accel/ivpu: Use cached buffers for FW loading")

from the drm-misc-fixes tree and commit:

  53d98420f5f9 ("accel/ivpu: Move ivpu_fw_load() to ivpu_fw_init()")

from the drm 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/accel/ivpu/ivpu_fw.c
index 0191cf8e5964,d57e103aae1c..000000000000
--- a/drivers/accel/ivpu/ivpu_fw.c
+++ b/drivers/accel/ivpu/ivpu_fw.c
@@@ -331,9 -332,7 +333,7 @@@ void ivpu_fw_load(struct ivpu_device *v
  		memset(start, 0, size);
  	}
  
 -	wmb(); /* Flush WC buffers after writing fw->mem */
 +	clflush_cache_range(fw->mem->kvaddr, fw->mem->base.size);
- 
- 	return 0;
  }
  
  static void ivpu_fw_boot_params_print(struct ivpu_device *vdev, struct vpu_boot_params *boot_params)

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

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

[Stephen Rothwell]

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

Hi all,

On Tue, 27 Jun 2023 11:54:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the drm tree got a conflict in:
> 
>   include/drm/gpu_scheduler.h
> 
> between commit:
> 
>   db8b4968a8d0 ("drm/sched: Call drm_sched_fence_set_parent() from drm_sched_fence_scheduled()")
> 
> from the drm-misc-fixes tree and commit:
> 
>   539f9ee4b52a ("drm/scheduler: properly forward fence errors")
> 
> from the drm 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.
> 
> diff --cc include/drm/gpu_scheduler.h
> index b29e347b10a9,e95b4837e5a3..000000000000
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@@ -581,16 -581,18 +581,17 @@@ void drm_sched_entity_push_job(struct d
>   void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
>   				   enum drm_sched_priority priority);
>   bool drm_sched_entity_is_ready(struct drm_sched_entity *entity);
> + int drm_sched_entity_error(struct drm_sched_entity *entity);
>   
>  -void drm_sched_fence_set_parent(struct drm_sched_fence *s_fence,
>  -				struct dma_fence *fence);
>   struct drm_sched_fence *drm_sched_fence_alloc(
>   	struct drm_sched_entity *s_entity, void *owner);
>   void drm_sched_fence_init(struct drm_sched_fence *fence,
>   			  struct drm_sched_entity *entity);
>   void drm_sched_fence_free(struct drm_sched_fence *fence);
>   
>  -void drm_sched_fence_scheduled(struct drm_sched_fence *fence);
>  +void drm_sched_fence_scheduled(struct drm_sched_fence *fence,
>  +			       struct dma_fence *parent);
> - void drm_sched_fence_finished(struct drm_sched_fence *fence);
> + void drm_sched_fence_finished(struct drm_sched_fence *fence, int result);
>   
>   unsigned long drm_sched_suspend_timeout(struct drm_gpu_scheduler *sched);
>   void drm_sched_resume_timeout(struct drm_gpu_scheduler *sched,

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

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/drm/gpu_scheduler.h

between commit:

  db8b4968a8d0 ("drm/sched: Call drm_sched_fence_set_parent() from drm_sched_fence_scheduled()")

from the drm-misc-fixes tree and commit:

  539f9ee4b52a ("drm/scheduler: properly forward fence errors")

from the drm 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 include/drm/gpu_scheduler.h
index b29e347b10a9,e95b4837e5a3..000000000000
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@@ -581,16 -581,18 +581,17 @@@ void drm_sched_entity_push_job(struct d
  void drm_sched_entity_set_priority(struct drm_sched_entity *entity,
  				   enum drm_sched_priority priority);
  bool drm_sched_entity_is_ready(struct drm_sched_entity *entity);
+ int drm_sched_entity_error(struct drm_sched_entity *entity);
  
 -void drm_sched_fence_set_parent(struct drm_sched_fence *s_fence,
 -				struct dma_fence *fence);
  struct drm_sched_fence *drm_sched_fence_alloc(
  	struct drm_sched_entity *s_entity, void *owner);
  void drm_sched_fence_init(struct drm_sched_fence *fence,
  			  struct drm_sched_entity *entity);
  void drm_sched_fence_free(struct drm_sched_fence *fence);
  
 -void drm_sched_fence_scheduled(struct drm_sched_fence *fence);
 +void drm_sched_fence_scheduled(struct drm_sched_fence *fence,
 +			       struct dma_fence *parent);
- void drm_sched_fence_finished(struct drm_sched_fence *fence);
+ void drm_sched_fence_finished(struct drm_sched_fence *fence, int result);
  
  unsigned long drm_sched_suspend_timeout(struct drm_gpu_scheduler *sched);
  void drm_sched_resume_timeout(struct drm_gpu_scheduler *sched,

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

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

[Stephen Rothwell]

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

Hi all,

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

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

between commit:

  b09d6acba1d9 ("drm/amdgpu: handle gang submit before VMID")

from the drm-misc-fixes tree and commits:

  c5093cddf56b ("drm/amdgpu: drop the fence argument from amdgpu_vmid_grab")
  940ca22b7ea9 ("drm/amdgpu: drop amdgpu_sync from amdgpu_vmid_grab v2")
  1b2d5eda5ad7 ("drm/amdgpu: move explicit sync check into the CS")
  1728baa7e4e6 ("drm/amdgpu: use scheduler dependencies for CS")

from the drm 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_job.c
index abb99cff8b4b,032651a655f0..000000000000
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@@ -243,30 -242,18 +242,18 @@@ amdgpu_job_prepare_job(struct drm_sched
  {
  	struct amdgpu_ring *ring = to_amdgpu_ring(s_entity->rq->sched);
  	struct amdgpu_job *job = to_amdgpu_job(sched_job);
- 	struct amdgpu_vm *vm = job->vm;
- 	struct dma_fence *fence;
+ 	struct dma_fence *fence = NULL;
  	int r;
  
- 	fence = amdgpu_sync_get_fence(&job->sync);
- 	if (fence && drm_sched_dependency_optimized(fence, s_entity)) {
- 		r = amdgpu_sync_fence(&job->sched_sync, fence);
- 		if (r)
- 			DRM_ERROR("Error adding fence (%d)\n", r);
- 	}
- 
- 	if (!fence && job->gang_submit)
++	if (job->gang_submit)
 +		fence = amdgpu_device_switch_gang(ring->adev, job->gang_submit);
 +
- 	while (fence == NULL && vm && !job->vmid) {
- 		r = amdgpu_vmid_grab(vm, ring, &job->sync,
- 				     &job->base.s_fence->finished,
- 				     job);
+ 	while (!fence && job->vm && !job->vmid) {
+ 		r = amdgpu_vmid_grab(job->vm, ring, job, &fence);
  		if (r)
  			DRM_ERROR("Error getting VM ID (%d)\n", r);
- 
- 		fence = amdgpu_sync_get_fence(&job->sync);
  	}
  
 -	if (!fence && job->gang_submit)
 -		fence = amdgpu_device_switch_gang(ring->adev, job->gang_submit);
 -
  	return fence;
  }
  

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

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

[Stephen Rothwell]

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

Hi Dave,

On Wed, 27 Jul 2022 13:24:45 +1000 Dave Airlie <airlied@gmail.com> wrote:
>
> My assumption is I fix this on sending my -next tree to Linus with a
> resolution I create at that time?
> 
> Is there another option, we have this fixed in out drm-tip tree already.

Sounds good, no problem.

-- 
Cheers,
Stephen Rothwell

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

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

[Dave Airlie]

On Wed, 27 Jul 2022 at 12:55, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Mon, 18 Jul 2022 09:44:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 11 Jul 2022 10:05:45 +0200 Christian König <christian.koenig@amd.com> wrote:
> > >
> > > Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> > > >
> > > > Today's linux-next merge of the drm tree got a conflict in:
> > > >
> > > >    drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > > >
> > > > between commit:
> > > >
> > > >    925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
> > > >
> > > > from the drm-misc-fixes tree and commit:
> > > >
> > > >    5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
> > > >
> > > > from the drm tree.
> > > >
> > > > This is a mess :-(  I have just reverted the above revert before mergin
> > > > the drm tree for today, please fix it up.
> > >
> > > Sorry for the noise, the patch "5e3f1e7729ec ("drm/amdgpu: fix start
> > > calculation in amdgpu_vram_mgr_new")" and another one is going to be
> > > reverted from the drm tree as well.
> > >
> > > It's just that -fixes patches where faster than -next patches.
> >
> > Here we are a week later, -rc7 has been released and as far as I can
> > tell (though I may have missed it), this is still a problem :-(
> >
> > I am still reverting 925b6e59138c (which is now in Linus' tree).
>
> Ping?

My assumption is I fix this on sending my -next tree to Linus with a
resolution I create at that time?

Is there another option, we have this fixed in out drm-tip tree already.

Dave.

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

[Stephen Rothwell]

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

Hi all,

On Mon, 18 Jul 2022 09:44:53 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 11 Jul 2022 10:05:45 +0200 Christian König <christian.koenig@amd.com> wrote:
> >
> > Am 11.07.22 um 04:47 schrieb Stephen Rothwell:  
> > >
> > > Today's linux-next merge of the drm tree got a conflict in:
> > >
> > >    drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > >
> > > between commit:
> > >
> > >    925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
> > >
> > > from the drm-misc-fixes tree and commit:
> > >
> > >    5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
> > >
> > > from the drm tree.
> > >
> > > This is a mess :-(  I have just reverted the above revert before mergin
> > > the drm tree for today, please fix it up.    
> > 
> > Sorry for the noise, the patch "5e3f1e7729ec ("drm/amdgpu: fix start
> > calculation in amdgpu_vram_mgr_new")" and another one is going to be
> > reverted from the drm tree as well.
> > 
> > It's just that -fixes patches where faster than -next patches.  
> 
> Here we are a week later, -rc7 has been released and as far as I can
> tell (though I may have missed it), this is still a problem :-(
> 
> I am still reverting 925b6e59138c (which is now in Linus' tree).

Ping?

-- 
Cheers,
Stephen Rothwell

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

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

[Geert Uytterhoeven]

Hi Stephen,

On Mon, Jul 18, 2022 at 1:49 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Mon, 11 Jul 2022 10:05:45 +0200 Christian König <christian.koenig@amd.com> wrote:
> > Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> > >
> > > Today's linux-next merge of the drm tree got a conflict in:
> > >
> > >    drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> > >
> > > between commit:
> > >
> > >    925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
> > >
> > > from the drm-misc-fixes tree and commit:
> > >
> > >    5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
> > >
> > > from the drm tree.
> > >
> > > This is a mess :-(  I have just reverted the above revert before mergin
> > > the drm tree for today, please fix it up.
> >
> > Sorry for the noise, the patch "5e3f1e7729ec ("drm/amdgpu: fix start
> > calculation in amdgpu_vram_mgr_new")" and another one is going to be
> > reverted from the drm tree as well.
> >
> > It's just that -fixes patches where faster than -next patches.
>
> Here we are a week later, -rc7 has been released and as far as I can
> tell (though I may have missed it), this is still a problem :-(
>
> I am still reverting 925b6e59138c (which is now in Linus' tree).

Thanks for the hint! After reverting that commit, drm-next (sort of[1])
merges cleanly into upstream again.

[1] There's still a small conflict due to the removal of
    force_dpms_off, cfr. the difference between commits
    3283c83eb6fcfbda and cc79950bf0904f58 ("drm/amd/display:
    Ensure valid event timestamp for cursor-only commits") in
    v5.19-rc7 resp. drm-next.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Stephen Rothwell]

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

Hi all,

On Mon, 11 Jul 2022 10:05:45 +0200 Christian König <christian.koenig@amd.com> wrote:
>
> Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> >
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> >    drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> >
> > between commit:
> >
> >    925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
> >
> > from the drm-misc-fixes tree and commit:
> >
> >    5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
> >
> > from the drm tree.
> >
> > This is a mess :-(  I have just reverted the above revert before mergin
> > the drm tree for today, please fix it up.  
> 
> Sorry for the noise, the patch "5e3f1e7729ec ("drm/amdgpu: fix start
> calculation in amdgpu_vram_mgr_new")" and another one is going to be
> reverted from the drm tree as well.
> 
> It's just that -fixes patches where faster than -next patches.

Here we are a week later, -rc7 has been released and as far as I can
tell (though I may have missed it), this is still a problem :-(

I am still reverting 925b6e59138c (which is now in Linus' tree).
-- 
Cheers,
Stephen Rothwell

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

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

[Christian König]

Hi Stephen,

Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
>    drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>
> between commit:
>
>    925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
>
> from the drm-misc-fixes tree and commit:
>
>    5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
>
> from the drm tree.
>
> This is a mess :-(  I have just reverted the above revert before mergin
> the drm tree for today, please fix it up.

Sorry for the noise, the patch "5e3f1e7729ec ("drm/amdgpu: fix start 
calculation in amdgpu_vram_mgr_new")" and another one is going to be 
reverted from the drm tree as well.

It's just that -fixes patches where faster than -next patches.

Regards,
Christian.


>

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

[Stephen Rothwell]

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

Hi all,

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

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

between commit:

  925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")

from the drm-misc-fixes tree and commit:

  5e3f1e7729ec ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")

from the drm tree.

This is a mess :-(  I have just reverted the above revert before mergin
the drm tree for today, please fix it up.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

On Fri, 18 Mar 2022 11:55:44 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
> 
>   drivers/gpu/drm/bridge/Kconfig
> 
> between commit:
> 
>   3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS")
> 
> from the drm-misc-fixes tree and commit:
> 
>   803abfd8dda5 ("drm: bridge: fix unmet dependency on DRM_KMS_HELPER for DRM_PANEL_BRIDGE")
> 
> from the drm tree.
> 
> I fixed it up (I just used the latter) and can carry the fix as

But that failed during configuration, so I went back and used the
former change.

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/bridge/Kconfig

between commit:

  3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS")

from the drm-misc-fixes tree and commit:

  803abfd8dda5 ("drm: bridge: fix unmet dependency on DRM_KMS_HELPER for DRM_PANEL_BRIDGE")

from the drm tree.

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

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

[Christian König]

Hi Stephen,

Am 22.12.21 um 04:50 schrieb Stephen Rothwell:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
>    drivers/gpu/drm/nouveau/nouveau_fence.c
>
> between commit:
>
>    67f74302f45d ("drm/nouveau: wait for the exclusive fence after the shared ones v2")
>
> from the drm-misc-fixes tree and commit:
>
>    40298cb45071 ("drm/nouveau: use the new iterator in nouveau_fence_sync")
>
> from the drm 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.
>

That will cause a performance regression in linux-next for nouveau users.

The real fix is already queued up for merging into drm-next. So no 
immediately action item here.

Just keep it in the back of your mind in case any nouveau users starts 
to complain about the performance in linux-next.

Thanks,
Christian.

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/nouveau/nouveau_fence.c

between commit:

  67f74302f45d ("drm/nouveau: wait for the exclusive fence after the shared ones v2")

from the drm-misc-fixes tree and commit:

  40298cb45071 ("drm/nouveau: use the new iterator in nouveau_fence_sync")

from the drm 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 --]

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

[Stephen Rothwell]

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

Hi Maxime,

On Tue, 30 Nov 2021 09:58:31 +0100 Maxime Ripard <maxime@cerno.tech> wrote:
>
> Unfortunately the merge resolution isn't entirely correct :/
> 
> There's multiple conflicts between those two branches on that file, but
> things went wrong between 16e101051f32 and 0c980a006d3f
> 
> The first one changes the logic a bit for the clk_set_min_rate argument,
> and the second moves the clk_set_min_rate around.
> 
> However, the merge resolution reintroduced the initial clk_set_min_rate
> call line (line 373), without changing the logic of the proper call site
> (line 396).
> 
> This is the patch to fix the resolution:
> 
> -- >8 --  
> --- a/drivers/gpu/drm/vc4/vc4_kms.c	2021-11-30 08:56:28.748524275 +0100
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c	2021-11-29 15:46:11.692151678 +0100
> @@ -365,14 +365,6 @@
>  		vc4_hvs_mask_underrun(dev, vc4_crtc_state->assigned_channel);
>  	}
> 
> -	if (vc4->hvs->hvs5) {
> -		unsigned long core_rate = max_t(unsigned long,
> -						500000000,
> -						new_hvs_state->core_clock_rate);
> -
> -		clk_set_min_rate(hvs->core_clk, core_rate);
> -	}
> -
>  	for (channel = 0; channel < HVS_NUM_CHANNELS; channel++) {
>  		struct drm_crtc_commit *commit;
>  		int ret;
> @@ -392,8 +384,13 @@
>  		old_hvs_state->fifo_state[channel].pending_commit = NULL;
>  	}
> 
> -	if (vc4->hvs->hvs5)
> -		clk_set_min_rate(hvs->core_clk, 500000000);
> +	if (vc4->hvs->hvs5) {
> +		unsigned long core_rate = max_t(unsigned long,
> +						500000000,
> +						new_hvs_state->core_clock_rate);
> +
> +		clk_set_min_rate(hvs->core_clk, core_rate);
> +	}
> 
>  	drm_atomic_helper_commit_modeset_disables(dev, state);
> -- >8 --  

Thanks, I have fixed that up in my resolution.

-- 
Cheers,
Stephen Rothwell

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

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

[Maxime Ripard]

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

Hi Stephen,

On Tue, Nov 30, 2021 at 10:33:53AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drm tree got a conflict in:
> 
>   drivers/gpu/drm/vc4/vc4_kms.c
> 
> between commits:
> 
>   f927767978d2 ("drm/vc4: kms: Fix return code check")
>   d354699e2292 ("drm/vc4: kms: Don't duplicate pending commit")
> 
> from the drm-misc-fixes tree and commit:
> 
>   16e101051f32 ("drm/vc4: Increase the core clock based on HVS load")
> 
> from the drm 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.

Unfortunately the merge resolution isn't entirely correct :/

There's multiple conflicts between those two branches on that file, but
things went wrong between 16e101051f32 and 0c980a006d3f

The first one changes the logic a bit for the clk_set_min_rate argument,
and the second moves the clk_set_min_rate around.

However, the merge resolution reintroduced the initial clk_set_min_rate
call line (line 373), without changing the logic of the proper call site
(line 396).

This is the patch to fix the resolution:

-- >8 --
--- a/drivers/gpu/drm/vc4/vc4_kms.c	2021-11-30 08:56:28.748524275 +0100
+++ b/drivers/gpu/drm/vc4/vc4_kms.c	2021-11-29 15:46:11.692151678 +0100
@@ -365,14 +365,6 @@
 		vc4_hvs_mask_underrun(dev, vc4_crtc_state->assigned_channel);
 	}

-	if (vc4->hvs->hvs5) {
-		unsigned long core_rate = max_t(unsigned long,
-						500000000,
-						new_hvs_state->core_clock_rate);
-
-		clk_set_min_rate(hvs->core_clk, core_rate);
-	}
-
 	for (channel = 0; channel < HVS_NUM_CHANNELS; channel++) {
 		struct drm_crtc_commit *commit;
 		int ret;
@@ -392,8 +384,13 @@
 		old_hvs_state->fifo_state[channel].pending_commit = NULL;
 	}

-	if (vc4->hvs->hvs5)
-		clk_set_min_rate(hvs->core_clk, 500000000);
+	if (vc4->hvs->hvs5) {
+		unsigned long core_rate = max_t(unsigned long,
+						500000000,
+						new_hvs_state->core_clock_rate);
+
+		clk_set_min_rate(hvs->core_clk, core_rate);
+	}

 	drm_atomic_helper_commit_modeset_disables(dev, state);
-- >8 --

I'm wondering though, do you have access to the drm-rerere tree? I've
fixed up the merge yesterday to deal with this conflict and the conflict
resolution should be stored there already.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/vc4/vc4_kms.c

between commits:

  f927767978d2 ("drm/vc4: kms: Fix return code check")
  d354699e2292 ("drm/vc4: kms: Don't duplicate pending commit")

from the drm-misc-fixes tree and commit:

  16e101051f32 ("drm/vc4: Increase the core clock based on HVS load")

from the drm 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_kms.c
index b61792d2aa65,79d4d9dd1394..000000000000
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@@ -337,12 -340,21 +340,21 @@@ static void vc4_atomic_commit_tail(stru
  	struct drm_device *dev = state->dev;
  	struct vc4_dev *vc4 = to_vc4_dev(dev);
  	struct vc4_hvs *hvs = vc4->hvs;
 -	struct drm_crtc_state *old_crtc_state;
  	struct drm_crtc_state *new_crtc_state;
+ 	struct vc4_hvs_state *new_hvs_state;
  	struct drm_crtc *crtc;
  	struct vc4_hvs_state *old_hvs_state;
 +	unsigned int channel;
  	int i;
  
+ 	old_hvs_state = vc4_hvs_get_old_global_state(state);
 -	if (WARN_ON(!old_hvs_state))
++	if (WARN_ON(IS_ERR(old_hvs_state)))
+ 		return;
+ 
+ 	new_hvs_state = vc4_hvs_get_new_global_state(state);
 -	if (WARN_ON(!new_hvs_state))
++	if (WARN_ON(IS_ERR(new_hvs_state)))
+ 		return;
+ 
  	for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
  		struct vc4_crtc_state *vc4_crtc_state;
  
@@@ -353,32 -365,31 +365,36 @@@
  		vc4_hvs_mask_underrun(dev, vc4_crtc_state->assigned_channel);
  	}
  
- 	old_hvs_state = vc4_hvs_get_old_global_state(state);
- 	if (IS_ERR(old_hvs_state))
- 		return;
+ 	if (vc4->hvs->hvs5) {
+ 		unsigned long core_rate = max_t(unsigned long,
+ 						500000000,
+ 						new_hvs_state->core_clock_rate);
+ 
+ 		clk_set_min_rate(hvs->core_clk, core_rate);
+ 	}
  
 -	for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
 -		struct vc4_crtc_state *vc4_crtc_state =
 -			to_vc4_crtc_state(old_crtc_state);
 -		unsigned int channel = vc4_crtc_state->assigned_channel;
 +	for (channel = 0; channel < HVS_NUM_CHANNELS; channel++) {
 +		struct drm_crtc_commit *commit;
  		int ret;
  
 -		if (channel == VC4_HVS_CHANNEL_DISABLED)
 +		if (!old_hvs_state->fifo_state[channel].in_use)
  			continue;
  
 -		if (!old_hvs_state->fifo_state[channel].in_use)
 +		commit = old_hvs_state->fifo_state[channel].pending_commit;
 +		if (!commit)
  			continue;
  
 -		ret = drm_crtc_commit_wait(old_hvs_state->fifo_state[channel].pending_commit);
 +		ret = drm_crtc_commit_wait(commit);
  		if (ret)
  			drm_err(dev, "Timed out waiting for commit\n");
 +
 +		drm_crtc_commit_put(commit);
 +		old_hvs_state->fifo_state[channel].pending_commit = NULL;
  	}
  
 +	if (vc4->hvs->hvs5)
 +		clk_set_min_rate(hvs->core_clk, 500000000);
 +
  	drm_atomic_helper_commit_modeset_disables(dev, state);
  
  	vc4_ctm_commit(vc4, state);
@@@ -667,11 -673,19 +678,13 @@@ vc4_hvs_channels_duplicate_state(struc
  
  	__drm_atomic_helper_private_obj_duplicate_state(obj, &state->base);
  
- 
  	for (i = 0; i < HVS_NUM_CHANNELS; i++) {
  		state->fifo_state[i].in_use = old_state->fifo_state[i].in_use;
+ 		state->fifo_state[i].fifo_load = old_state->fifo_state[i].fifo_load;
 -
 -		if (!old_state->fifo_state[i].pending_commit)
 -			continue;
 -
 -		state->fifo_state[i].pending_commit =
 -			drm_crtc_commit_get(old_state->fifo_state[i].pending_commit);
  	}
  
+ 	state->core_clock_rate = old_state->core_clock_rate;
+ 
  	return &state->base;
  }
  
@@@ -826,6 -840,76 +839,76 @@@ static int vc4_pv_muxing_atomic_check(s
  	return 0;
  }
  
+ static int
+ vc4_core_clock_atomic_check(struct drm_atomic_state *state)
+ {
+ 	struct vc4_dev *vc4 = to_vc4_dev(state->dev);
+ 	struct drm_private_state *priv_state;
+ 	struct vc4_hvs_state *hvs_new_state;
+ 	struct vc4_load_tracker_state *load_state;
+ 	struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ 	struct drm_crtc *crtc;
+ 	unsigned int num_outputs;
+ 	unsigned long pixel_rate;
+ 	unsigned long cob_rate;
+ 	unsigned int i;
+ 
+ 	priv_state = drm_atomic_get_private_obj_state(state,
+ 						      &vc4->load_tracker);
+ 	if (IS_ERR(priv_state))
+ 		return PTR_ERR(priv_state);
+ 
+ 	load_state = to_vc4_load_tracker_state(priv_state);
+ 
+ 	hvs_new_state = vc4_hvs_get_global_state(state);
 -	if (!hvs_new_state)
 -		return -EINVAL;
++	if (IS_ERR(hvs_new_state))
++		return PTR_ERR(hvs_new_state);
+ 
+ 	for_each_oldnew_crtc_in_state(state, crtc,
+ 				      old_crtc_state,
+ 				      new_crtc_state,
+ 				      i) {
+ 		if (old_crtc_state->active) {
+ 			struct vc4_crtc_state *old_vc4_state =
+ 				to_vc4_crtc_state(old_crtc_state);
+ 			unsigned int channel = old_vc4_state->assigned_channel;
+ 
+ 			hvs_new_state->fifo_state[channel].fifo_load = 0;
+ 		}
+ 
+ 		if (new_crtc_state->active) {
+ 			struct vc4_crtc_state *new_vc4_state =
+ 				to_vc4_crtc_state(new_crtc_state);
+ 			unsigned int channel = new_vc4_state->assigned_channel;
+ 
+ 			hvs_new_state->fifo_state[channel].fifo_load =
+ 				new_vc4_state->hvs_load;
+ 		}
+ 	}
+ 
+ 	cob_rate = 0;
+ 	num_outputs = 0;
+ 	for (i = 0; i < HVS_NUM_CHANNELS; i++) {
+ 		if (!hvs_new_state->fifo_state[i].in_use)
+ 			continue;
+ 
+ 		num_outputs++;
+ 		cob_rate += hvs_new_state->fifo_state[i].fifo_load;
+ 	}
+ 
+ 	pixel_rate = load_state->hvs_load;
+ 	if (num_outputs > 1) {
+ 		pixel_rate = (pixel_rate * 40) / 100;
+ 	} else {
+ 		pixel_rate = (pixel_rate * 60) / 100;
+ 	}
+ 
+ 	hvs_new_state->core_clock_rate = max(cob_rate, pixel_rate);
+ 
+ 	return 0;
+ }
+ 
+ 
  static int
  vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
  {

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/drm_panel_orientation_quirks.c

between commit:

  def0c3697287 ("drm: panel-orientation-quirks: Add quirk for Aya Neo 2021")

from the drm-misc-fixes tree and commits:

  072e70d52372 ("drm: panel-orientation-quirks: Add quirk for the Chuwi Hi10 Pro")
  63a4881572d7 ("drm: panel-orientation-quirks: Add quirk for the Chuwi HiBook")

from the drm 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_panel_orientation_quirks.c
index 30c17a76f49a,62e8ccc7ab9c..000000000000
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@@ -134,12 -140,20 +140,26 @@@ static const struct dmi_system_id orien
  		  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T103HAF"),
  		},
  		.driver_data = (void *)&lcd800x1280_rightside_up,
 +	}, {	/* AYA NEO 2021 */
 +		.matches = {
 +		  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "AYADEVICE"),
 +		  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "AYA NEO 2021"),
 +		},
 +		.driver_data = (void *)&lcd800x1280_rightside_up,
+ 	}, {	/* Chuwi HiBook (CWI514) */
+ 		.matches = {
+ 			DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ 			DMI_MATCH(DMI_BOARD_NAME, "Cherry Trail CR"),
+ 			/* Above matches are too generic, add bios-date match */
+ 			DMI_MATCH(DMI_BIOS_DATE, "05/07/2016"),
+ 		},
+ 		.driver_data = (void *)&lcd1200x1920_rightside_up,
+ 	}, {	/* Chuwi Hi10 Pro (CWI529) */
+ 		.matches = {
+ 		  DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
+ 		  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Hi10 pro tablet"),
+ 		},
+ 		.driver_data = (void *)&lcd1200x1920_rightside_up,
  	}, {	/* GPD MicroPC (generic strings, also match on bios date) */
  		.matches = {
  		  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/vc4/vc4_hdmi.c

between commit:

  9984d6664ce9 ("drm/vc4: hdmi: Make sure the controller is powered in detect")

from the drm-misc-fixes tree and commit:

  6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod")

from the drm 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_hdmi.c
index 8106b5634fe1,3c4cc133e3df..000000000000
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@@ -159,12 -166,9 +166,11 @@@ vc4_hdmi_connector_detect(struct drm_co
  	struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
  	bool connected = false;
  
 +	WARN_ON(pm_runtime_resume_and_get(&vc4_hdmi->pdev->dev));
 +
- 	if (vc4_hdmi->hpd_gpio) {
- 		if (gpio_get_value_cansleep(vc4_hdmi->hpd_gpio) ^
- 		    vc4_hdmi->hpd_active_low)
- 			connected = true;
+ 	if (vc4_hdmi->hpd_gpio &&
+ 	    gpiod_get_value_cansleep(vc4_hdmi->hpd_gpio)) {
+ 		connected = true;
  	} else if (drm_probe_ddc(vc4_hdmi->ddc)) {
  		connected = true;
  	} else if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED) {
@@@ -787,16 -942,26 +945,18 @@@ static void vc4_hdmi_encoder_pre_crtc_c
  		return;
  	}
  
 -	ret = clk_prepare_enable(vc4_hdmi->hsm_clock);
 -	if (ret) {
 -		DRM_ERROR("Failed to turn on HSM clock: %d\n", ret);
 -		clk_disable_unprepare(vc4_hdmi->pixel_clock);
 -		return;
 -	}
 -
  	vc4_hdmi_cec_update_clk_div(vc4_hdmi);
  
- 	/*
- 	 * FIXME: When the pixel freq is 594MHz (4k60), this needs to be setup
- 	 * at 300MHz.
- 	 */
- 	ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock,
- 			       (hsm_rate > VC4_HSM_MID_CLOCK ? 150000000 : 75000000));
+ 	if (pixel_rate > 297000000)
+ 		bvb_rate = 300000000;
+ 	else if (pixel_rate > 148500000)
+ 		bvb_rate = 150000000;
+ 	else
+ 		bvb_rate = 75000000;
+ 
+ 	ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock, bvb_rate);
  	if (ret) {
  		DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
 -		clk_disable_unprepare(vc4_hdmi->hsm_clock);
  		clk_disable_unprepare(vc4_hdmi->pixel_clock);
  		return;
  	}

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/vc4/vc4_plane.c

between commit:

  35d65ab3fdba ("drm/vc4: plane: Remove redundant assignment")

from the drm-misc-fixes tree and commit:

  5ddb0bd4ddc3 ("drm/atomic: Pass the full state to planes async atomic check and update")

from the drm 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_plane.c
index 1e9c84cf614a,c76e73a452e0..000000000000
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@@ -1133,31 -1135,34 +1135,33 @@@ void vc4_plane_async_set_fb(struct drm_
  }
  
  static void vc4_plane_atomic_async_update(struct drm_plane *plane,
- 					  struct drm_plane_state *state)
+ 					  struct drm_atomic_state *state)
  {
+ 	struct drm_plane_state *new_plane_state = drm_atomic_get_new_plane_state(state,
+ 										 plane);
  	struct vc4_plane_state *vc4_state, *new_vc4_state;
  
- 	swap(plane->state->fb, state->fb);
- 	plane->state->crtc_x = state->crtc_x;
- 	plane->state->crtc_y = state->crtc_y;
- 	plane->state->crtc_w = state->crtc_w;
- 	plane->state->crtc_h = state->crtc_h;
- 	plane->state->src_x = state->src_x;
- 	plane->state->src_y = state->src_y;
- 	plane->state->src_w = state->src_w;
- 	plane->state->src_h = state->src_h;
- 	plane->state->alpha = state->alpha;
- 	plane->state->pixel_blend_mode = state->pixel_blend_mode;
- 	plane->state->rotation = state->rotation;
- 	plane->state->zpos = state->zpos;
- 	plane->state->normalized_zpos = state->normalized_zpos;
- 	plane->state->color_encoding = state->color_encoding;
- 	plane->state->color_range = state->color_range;
- 	plane->state->src = state->src;
- 	plane->state->dst = state->dst;
- 	plane->state->visible = state->visible;
- 
- 	new_vc4_state = to_vc4_plane_state(state);
+ 	swap(plane->state->fb, new_plane_state->fb);
+ 	plane->state->crtc_x = new_plane_state->crtc_x;
+ 	plane->state->crtc_y = new_plane_state->crtc_y;
+ 	plane->state->crtc_w = new_plane_state->crtc_w;
+ 	plane->state->crtc_h = new_plane_state->crtc_h;
+ 	plane->state->src_x = new_plane_state->src_x;
+ 	plane->state->src_y = new_plane_state->src_y;
+ 	plane->state->src_w = new_plane_state->src_w;
+ 	plane->state->src_h = new_plane_state->src_h;
 -	plane->state->src_h = new_plane_state->src_h;
+ 	plane->state->alpha = new_plane_state->alpha;
+ 	plane->state->pixel_blend_mode = new_plane_state->pixel_blend_mode;
+ 	plane->state->rotation = new_plane_state->rotation;
+ 	plane->state->zpos = new_plane_state->zpos;
+ 	plane->state->normalized_zpos = new_plane_state->normalized_zpos;
+ 	plane->state->color_encoding = new_plane_state->color_encoding;
+ 	plane->state->color_range = new_plane_state->color_range;
+ 	plane->state->src = new_plane_state->src;
+ 	plane->state->dst = new_plane_state->dst;
+ 	plane->state->visible = new_plane_state->visible;
+ 
+ 	new_vc4_state = to_vc4_plane_state(new_plane_state);
  	vc4_state = to_vc4_plane_state(plane->state);
  
  	vc4_state->crtc_x = new_vc4_state->crtc_x;

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/drm_gem.c

between commit:

  8490d6a7e0a0 ("drm: hold gem reference until object is no longer accessed")

from the drm-misc-fixes tree and commit:

  be6ee102341b ("drm: remove _unlocked suffix in drm_gem_object_put_unlocked")

from the drm 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 ee2058ad482c,a57f5379fc08..000000000000
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@@ -901,9 -913,7 +909,9 @@@ drm_gem_open_ioctl(struct drm_device *d
  	args->handle = handle;
  	args->size = obj->size;
  
 -	return 0;
 +err:
- 	drm_gem_object_put_unlocked(obj);
++	drm_gem_object_put(obj);
 +	return ret;
  }
  
  /**

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

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

[Stephen Rothwell]

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

Hi all,

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

  include/linux/dma-buf.h

between commit:

  6f49c2515e22 ("dma-buf: fix documentation build warnings")

from the drm-misc-fixes tree and commit:

  09606b5446c2 ("dma-buf: add peer2peer flag")

from the drm 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 include/linux/dma-buf.h
index 57bcef6f988a,82e0a4a64601..000000000000
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@@ -333,8 -334,16 +333,16 @@@ struct dma_buf 
   * Attachment operations implemented by the importer.
   */
  struct dma_buf_attach_ops {
+ 	/**
+ 	 * @allow_peer2peer:
+ 	 *
+ 	 * If this is set to true the importer must be able to handle peer
+ 	 * resources without struct pages.
+ 	 */
+ 	bool allow_peer2peer;
+ 
  	/**
 -	 * @move_notify
 +	 * @move_notify: [optional] notification that the DMA-buf is moving
  	 *
  	 * If this callback is provided the framework can avoid pinning the
  	 * backing store while mappings exists.

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/virtio/virtgpu_object.c

between commit:

  6be7e0733548 ("drm/virtio: fix mmap page attributes")

from the drm-misc-fixes tree and commit:

  18b39fb975b7 ("drm/virtio: add virtio_gpu_is_shmem helper")

from the drm 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/virtio/virtgpu_object.c
index 3af7ec80c7da,c5cad949eb8d..000000000000
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@@ -98,8 -123,7 +123,8 @@@ struct drm_gem_object *virtio_gpu_creat
  	if (!bo)
  		return NULL;
  
- 	bo->base.base.funcs = &virtio_gpu_gem_funcs;
+ 	bo->base.base.funcs = &virtio_gpu_shmem_funcs;
 +	bo->base.map_cached = true;
  	return &bo->base.base;
  }
  

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

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

[Qiang Yu]

On Mon, Sep 16, 2019 at 1:30 PM Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>
> On Sun, Sep 15, 2019 at 2:18 PM Mark Brown <broonie@kernel.org> wrote:
> >
> > Hi all,
>
> Hi Mark,
>
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> >   drivers/gpu/drm/lima/lima_gem.c
> >
> > between commit:
> >
> >   21670bd78a25001cf8e ("drm/lima: fix lima_gem_wait() return value")
> >
> > from the drm-misc-fixes tree and commit:
> >
> >   52791eeec1d9f4a7e7f ("dma-buf: rename reservation_object to dma_resv")
> >
> > from the drm 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.
>
> Fix looks correct to me. Sorry for not testing my patch with
> linux-next, I'll make sure it at least compiles next time.

This is merge conflict, not compile fail, because linux-next and drm-misc-fixes
are based on different code base, so drm-misc-fixes do not contain latest drm
commits.

This conflict solve change is also OK for me.

Thanks,
Qiang

>
> > diff --cc drivers/gpu/drm/lima/lima_gem.c
> > index b609dc030d6ca,ff3d9acc24fcf..0000000000000
> > --- a/drivers/gpu/drm/lima/lima_gem.c
> > +++ b/drivers/gpu/drm/lima/lima_gem.c
> > @@@ -341,8 -341,8 +341,8 @@@ int lima_gem_wait(struct drm_file *file
> >
> >         timeout = drm_timeout_abs_to_jiffies(timeout_ns);
> >
> > -       ret = drm_gem_reservation_object_wait(file, handle, write, timeout);
> > +       ret = drm_gem_dma_resv_wait(file, handle, write, timeout);
> >  -      if (ret == 0)
> >  +      if (ret == -ETIME)
> >                 ret = timeout ? -ETIMEDOUT : -EBUSY;
> >
> >         return ret;

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

[Vasily Khoruzhick]

On Sun, Sep 15, 2019 at 2:18 PM Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,

Hi Mark,

> Today's linux-next merge of the drm tree got a conflict in:
>
>   drivers/gpu/drm/lima/lima_gem.c
>
> between commit:
>
>   21670bd78a25001cf8e ("drm/lima: fix lima_gem_wait() return value")
>
> from the drm-misc-fixes tree and commit:
>
>   52791eeec1d9f4a7e7f ("dma-buf: rename reservation_object to dma_resv")
>
> from the drm 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.

Fix looks correct to me. Sorry for not testing my patch with
linux-next, I'll make sure it at least compiles next time.

> diff --cc drivers/gpu/drm/lima/lima_gem.c
> index b609dc030d6ca,ff3d9acc24fcf..0000000000000
> --- a/drivers/gpu/drm/lima/lima_gem.c
> +++ b/drivers/gpu/drm/lima/lima_gem.c
> @@@ -341,8 -341,8 +341,8 @@@ int lima_gem_wait(struct drm_file *file
>
>         timeout = drm_timeout_abs_to_jiffies(timeout_ns);
>
> -       ret = drm_gem_reservation_object_wait(file, handle, write, timeout);
> +       ret = drm_gem_dma_resv_wait(file, handle, write, timeout);
>  -      if (ret == 0)
>  +      if (ret == -ETIME)
>                 ret = timeout ? -ETIMEDOUT : -EBUSY;
>
>         return ret;

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

[Mark Brown]

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

Hi all,

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

  drivers/gpu/drm/lima/lima_gem.c

between commit:

  21670bd78a25001cf8e ("drm/lima: fix lima_gem_wait() return value")

from the drm-misc-fixes tree and commit:

  52791eeec1d9f4a7e7f ("dma-buf: rename reservation_object to dma_resv")

from the drm 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.

diff --cc drivers/gpu/drm/lima/lima_gem.c
index b609dc030d6ca,ff3d9acc24fcf..0000000000000
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@@ -341,8 -341,8 +341,8 @@@ int lima_gem_wait(struct drm_file *file
  
  	timeout = drm_timeout_abs_to_jiffies(timeout_ns);
  
- 	ret = drm_gem_reservation_object_wait(file, handle, write, timeout);
+ 	ret = drm_gem_dma_resv_wait(file, handle, write, timeout);
 -	if (ret == 0)
 +	if (ret == -ETIME)
  		ret = timeout ? -ETIMEDOUT : -EBUSY;
  
  	return ret;

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

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

[james qian wang (Arm Technology China)]

On Mon, Aug 26, 2019 at 01:06:37PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drm tree got a conflict in:
> 
>   drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> 
> between commit:
> 
>   51a44a28eefd ("drm/komeda: Add missing of_node_get() call")
> 
> from the drm-misc-fixes tree and commit:
> 
>   8965ad8433ea ("drm/komeda: Enable dual-link support")
> 
> from the drm 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.
>

Hi Stephen:
Sorry for the conflict, and thank you very much.

Regards
James
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 9d4d5075cc64,1ff7f4b2c620..000000000000
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@@ -127,7 -128,8 +129,8 @@@ static int komeda_parse_pipe_dt(struct 
>   	pipe->of_output_port =
>   		of_graph_get_port_by_id(np, KOMEDA_OF_PORT_OUTPUT);
>   
> + 	pipe->dual_link = pipe->of_output_links[0] && pipe->of_output_links[1];
>  -	pipe->of_node = np;
>  +	pipe->of_node = of_node_get(np);
>   
>   	return 0;
>   }

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/arm/display/komeda/komeda_dev.c

between commit:

  51a44a28eefd ("drm/komeda: Add missing of_node_get() call")

from the drm-misc-fixes tree and commit:

  8965ad8433ea ("drm/komeda: Enable dual-link support")

from the drm 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/arm/display/komeda/komeda_dev.c
index 9d4d5075cc64,1ff7f4b2c620..000000000000
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@@ -127,7 -128,8 +129,8 @@@ static int komeda_parse_pipe_dt(struct 
  	pipe->of_output_port =
  		of_graph_get_port_by_id(np, KOMEDA_OF_PORT_OUTPUT);
  
+ 	pipe->dual_link = pipe->of_output_links[0] && pipe->of_output_links[1];
 -	pipe->of_node = np;
 +	pipe->of_node = of_node_get(np);
  
  	return 0;
  }

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/meson/meson_crtc.c

between commit:

  47ebfb6ed13e ("drm/meson: Fixes for drm_crtc_vblank_on/off support")

from the drm-misc-fixes tree and commit:

  f9a2348196d1 ("drm/meson: Support Overlay plane for video rendering")

from the drm 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/meson/meson_crtc.c
index 191b314f9e9e,d78168f979db..000000000000
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@@ -126,8 -115,8 +131,10 @@@ static void meson_crtc_atomic_disable(s
  	struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
  	struct meson_drm *priv = meson_crtc->priv;
  
+ 	DRM_DEBUG_DRIVER("\n");
+ 
 +	drm_crtc_vblank_off(crtc);
 +
  	priv->viu.osd1_enabled = false;
  	priv->viu.osd1_commit = false;
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/sun4i/sun4i_tcon.c

between commit:

  e742a17cd360 ("drm/sun4i: tcon: Reduce the scope of the LVDS error a bit")

from the drm-misc-fixes tree and commit:

  34d698f6e349 ("drm/sun4i: Add has_channel_0 TCON quirk")

from the drm 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/sun4i/sun4i_tcon.c
index 2de586b7c98b,0d6c5ed44795..000000000000
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@@ -1143,11 -1155,15 +1164,16 @@@ static const struct sun4i_tcon_quirks s
  };
  
  static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
+ 	.has_channel_0		= true,
 +	.supports_lvds		= true,
  };
  
+ static const struct sun4i_tcon_quirks sun8i_a83t_tv_quirks = {
+ 	.has_channel_1		= true,
+ };
+ 
  static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
- 	/* nothing is supported */
+ 	.has_channel_0		= true,
  };
  
  /* sun4i_drv uses this list to check if a device node is a TCON */

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

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

[Stephen Rothwell]

Hi all,

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

  drivers/gpu/drm/drm_edid.c

between commit:

  4b4df570b41d ("drm: Update edid-derived drm_display_info fields at edid property set [v2]")

from the drm-misc-fixes tree and commit:

  c945b8c14bb7 ("drm/edid: build ELD in drm_add_edid_modes()")

from the drm 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_edid.c
index cb487148359a,524eace3d460..000000000000
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@@ -4653,6 -4645,10 +4671,8 @@@ int drm_add_edid_modes(struct drm_conne
  		return 0;
  	}
  
 -	quirks = edid_get_quirks(edid);
 -
+ 	drm_edid_to_eld(connector, edid);
+ 
  	/*
  	 * CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
  	 * To avoid multiple parsing of same block, lets parse that map

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

[Stephen Rothwell]

Hi Dave,

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

  include/drm/drm_atomic.h

between commit:

  7e9081c5aac7 ("drm/fence: fix memory overwrite when setting out_fence fd")

from the drm-misc-fixes tree and commit:

  bdc571464c49 ("drm/atomic: Clean up wait_for_vblanks, v2.")

from the drm 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 include/drm/drm_atomic.h
index 56814e8ae7ea,f96220ed4004..000000000000
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@@ -144,7 -144,8 +144,8 @@@ struct __drm_crtcs_state 
  	struct drm_crtc *ptr;
  	struct drm_crtc_state *state;
  	struct drm_crtc_commit *commit;
 -	s64 __user *out_fence_ptr;
 +	s32 __user *out_fence_ptr;
+ 	unsigned last_vblank_count;
  };
  
  struct __drm_connnectors_state {