linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2017-12-13 23:59 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2017-12-13 23:59 UTC (permalink / raw)
  To: Dave Airlie, DRI, Daniel Vetter, Intel Graphics
  Cc: Jani Nikula, Keith Packard, Linux-Next Mailing List,
	Linux Kernel Mailing List

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
  2022-03-18  0:55 Stephen Rothwell
@ 2022-03-18  1:06 ` Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2022-03-18  1:06 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics
  Cc: DRI, Julian Braha, Linux Kernel Mailing List,
	Linux Next Mailing List, Robert Foss, Thomas Zimmermann

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2022-03-18  0:55 Stephen Rothwell
  2022-03-18  1:06 ` Stephen Rothwell
  0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2022-03-18  0:55 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics
  Cc: DRI, Julian Braha, Linux Kernel Mailing List,
	Linux Next Mailing List, Robert Foss, Thomas Zimmermann

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

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

* Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
  2021-12-22  3:50 Stephen Rothwell
@ 2021-12-22  7:31 ` Christian König
  0 siblings, 0 replies; 24+ messages in thread
From: Christian König @ 2021-12-22  7:31 UTC (permalink / raw)
  To: Stephen Rothwell, Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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.

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2021-12-22  3:50 Stephen Rothwell
  2021-12-22  7:31 ` Christian König
  0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2021-12-22  3:50 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: Christian König, Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
  2021-11-30  8:58 ` Maxime Ripard
@ 2021-11-30 20:35   ` Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2021-11-30 20:35 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Dave Airlie, Daniel Vetter, Intel Graphics, DRI,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
  2021-11-29 23:33 Stephen Rothwell
@ 2021-11-30  8:58 ` Maxime Ripard
  2021-11-30 20:35   ` Stephen Rothwell
  0 siblings, 1 reply; 24+ messages in thread
From: Maxime Ripard @ 2021-11-30  8:58 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Dave Airlie, Daniel Vetter, Intel Graphics, DRI,
	Linux Kernel Mailing List, Linux Next Mailing List

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2021-11-29 23:33 Stephen Rothwell
  2021-11-30  8:58 ` Maxime Ripard
  0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2021-11-29 23:33 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Maxime Ripard

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2021-10-22  0:53 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2021-10-22  0:53 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: Bryant Mairs, Hans de Goede, Linux Kernel Mailing List,
	Linux Next Mailing List, Sam Ravnborg

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2021-06-17  1:42 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2021-06-17  1:42 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Maxime Ripard

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2021-04-09  3:12 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2021-04-09  3:12 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Maxime Ripard

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

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

* Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
  2021-03-18  1:02 Stephen Rothwell
@ 2021-03-18  6:51 ` Tomi Valkeinen
  0 siblings, 0 replies; 24+ messages in thread
From: Tomi Valkeinen @ 2021-03-18  6:51 UTC (permalink / raw)
  To: Stephen Rothwell, Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: Junlin Yang, Linux Kernel Mailing List, Linux Next Mailing List,
	Menglong Dong

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2021-03-18  1:02 Stephen Rothwell
  2021-03-18  6:51 ` Tomi Valkeinen
  0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2021-03-18  1:02 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: Junlin Yang, Linux Kernel Mailing List, Linux Next Mailing List,
	Menglong Dong, Tomi Valkeinen

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2020-07-28  3:41 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2020-07-28  3:41 UTC (permalink / raw)
  To: Dave Airlie, DRI, Daniel Vetter, Intel Graphics
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Steve Cohen,
	Emil Velikov

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2020-05-01  3:45 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2020-05-01  3:45 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Randy Dunlap,
	Sumit Semwal, Christian König

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2020-03-01 23:43 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2020-03-01 23:43 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Gerd Hoffmann, Gurchetan Singh

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

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

* Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
  2019-09-16  5:29 ` Vasily Khoruzhick
@ 2019-09-17  2:43   ` Qiang Yu
  0 siblings, 0 replies; 24+ messages in thread
From: Qiang Yu @ 2019-09-17  2:43 UTC (permalink / raw)
  To: Vasily Khoruzhick
  Cc: Mark Brown, Christian König, Chris Wilson, Dave Airlie, DRI,
	Linux Next Mailing List, Linux Kernel Mailing List

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;

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

* Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
  2019-09-15 21:18 Mark Brown
@ 2019-09-16  5:29 ` Vasily Khoruzhick
  2019-09-17  2:43   ` Qiang Yu
  0 siblings, 1 reply; 24+ messages in thread
From: Vasily Khoruzhick @ 2019-09-16  5:29 UTC (permalink / raw)
  To: Mark Brown
  Cc: Qiang Yu, Christian König, Chris Wilson, Dave Airlie, DRI,
	Linux Next Mailing List, Linux Kernel Mailing List

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;

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2019-09-15 21:18 Mark Brown
  2019-09-16  5:29 ` Vasily Khoruzhick
  0 siblings, 1 reply; 24+ messages in thread
From: Mark Brown @ 2019-09-15 21:18 UTC (permalink / raw)
  To: Vasily Khoruzhick, Qiang Yu, Christian König, Chris Wilson,
	Dave Airlie, DRI
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

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

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

* Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
  2019-08-26  3:06 Stephen Rothwell
@ 2019-08-29 10:11 ` james qian wang (Arm Technology China)
  0 siblings, 0 replies; 24+ messages in thread
From: james qian wang (Arm Technology China) @ 2019-08-29 10:11 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Dave Airlie, DRI, Daniel Vetter, Intel Graphics,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Mihail Atanassov, Ayan Halder, Liviu Dudau, nd

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;
>   }



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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2019-08-26  3:06 Stephen Rothwell
  2019-08-29 10:11 ` james qian wang (Arm Technology China)
  0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2019-08-26  3:06 UTC (permalink / raw)
  To: Dave Airlie, DRI, Daniel Vetter, Intel Graphics
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Mihail Atanassov, Ayan kumar halder,
	James Qian Wang (Arm Technology China),
	Liviu Dudau

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2018-11-26  2:37 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2018-11-26  2:37 UTC (permalink / raw)
  To: Dave Airlie, DRI, Daniel Vetter, Intel Graphics
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Neil Armstrong, Lyude Paul

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2018-03-08  0:47 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2018-03-08  0:47 UTC (permalink / raw)
  To: Dave Airlie, DRI, Daniel Vetter, Intel Graphics
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Jernej Skrabec, Maxime Ripard

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

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

* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
@ 2017-01-17  0:59 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2017-01-17  0:59 UTC (permalink / raw)
  To: Dave Airlie, Daniel Vetter, Intel Graphics, DRI
  Cc: linux-next, linux-kernel, Gustavo Padovan, Maarten Lankhorst

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 {

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

end of thread, other threads:[~2022-03-18  1:06 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-13 23:59 linux-next: manual merge of the drm tree with the drm-misc-fixes tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2022-03-18  0:55 Stephen Rothwell
2022-03-18  1:06 ` Stephen Rothwell
2021-12-22  3:50 Stephen Rothwell
2021-12-22  7:31 ` Christian König
2021-11-29 23:33 Stephen Rothwell
2021-11-30  8:58 ` Maxime Ripard
2021-11-30 20:35   ` Stephen Rothwell
2021-10-22  0:53 Stephen Rothwell
2021-06-17  1:42 Stephen Rothwell
2021-04-09  3:12 Stephen Rothwell
2021-03-18  1:02 Stephen Rothwell
2021-03-18  6:51 ` Tomi Valkeinen
2020-07-28  3:41 Stephen Rothwell
2020-05-01  3:45 Stephen Rothwell
2020-03-01 23:43 Stephen Rothwell
2019-09-15 21:18 Mark Brown
2019-09-16  5:29 ` Vasily Khoruzhick
2019-09-17  2:43   ` Qiang Yu
2019-08-26  3:06 Stephen Rothwell
2019-08-29 10:11 ` james qian wang (Arm Technology China)
2018-11-26  2:37 Stephen Rothwell
2018-03-08  0:47 Stephen Rothwell
2017-01-17  0:59 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).