[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 1723 bytes --]

Hi all,

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

  drivers/gpu/drm/i915/gvt/vgpu.c

between commit:

  04d6067f1f19 ("drm/i915/gvt: Fix unnecessary schedule timer when no vGPU exits")

from the drm-intel-fixes tree and commit:

  12d5861973c7 ("drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available")

from the drm-intel 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/i915/gvt/vgpu.c
index 345c2aa3b491,abcde8ce1a9a..000000000000
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@@ -271,18 -272,12 +272,19 @@@ void intel_gvt_release_vgpu(struct inte
  void intel_gvt_destroy_vgpu(struct intel_vgpu *vgpu)
  {
  	struct intel_gvt *gvt = vgpu->gvt;
+ 	struct drm_i915_private *i915 = gvt->gt->i915;
  
- 	WARN(vgpu->active, "vGPU is still active!\n");
 -	mutex_lock(&vgpu->vgpu_lock);
 -
+ 	drm_WARN(&i915->drm, vgpu->active, "vGPU is still active!\n");
  
 +	/*
 +	 * remove idr first so later clean can judge if need to stop
 +	 * service if no active vgpu.
 +	 */
 +	mutex_lock(&gvt->lock);
 +	idr_remove(&gvt->vgpu_idr, vgpu->id);
 +	mutex_unlock(&gvt->lock);
 +
 +	mutex_lock(&vgpu->vgpu_lock);
  	intel_gvt_debugfs_remove_vgpu(vgpu);
  	intel_vgpu_clean_sched_policy(vgpu);
  	intel_vgpu_clean_submission(vgpu);

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 2011 bytes --]

Hi all,

On Wed, 11 Mar 2020 13:36:35 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
> 
>   drivers/gpu/drm/i915/gvt/vgpu.c
> 
> between commit:
> 
>   04d6067f1f19 ("drm/i915/gvt: Fix unnecessary schedule timer when no vGPU exits")
> 
> from the drm-intel-fixes tree and commit:
> 
>   12d5861973c7 ("drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available")
> 
> from the drm-intel 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/i915/gvt/vgpu.c
> index 345c2aa3b491,abcde8ce1a9a..000000000000
> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> @@@ -271,18 -272,12 +272,19 @@@ void intel_gvt_release_vgpu(struct inte
>   void intel_gvt_destroy_vgpu(struct intel_vgpu *vgpu)
>   {
>   	struct intel_gvt *gvt = vgpu->gvt;
> + 	struct drm_i915_private *i915 = gvt->gt->i915;
>   
> - 	WARN(vgpu->active, "vGPU is still active!\n");
>  -	mutex_lock(&vgpu->vgpu_lock);
>  -
> + 	drm_WARN(&i915->drm, vgpu->active, "vGPU is still active!\n");
>   
>  +	/*
>  +	 * remove idr first so later clean can judge if need to stop
>  +	 * service if no active vgpu.
>  +	 */
>  +	mutex_lock(&gvt->lock);
>  +	idr_remove(&gvt->vgpu_idr, vgpu->id);
>  +	mutex_unlock(&gvt->lock);
>  +
>  +	mutex_lock(&vgpu->vgpu_lock);
>   	intel_gvt_debugfs_remove_vgpu(vgpu);
>   	intel_vgpu_clean_sched_policy(vgpu);
>   	intel_vgpu_clean_submission(vgpu);

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

-- 
Cheers,
Stephen Rothwell

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[broonie]

Hi all,

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

  drivers/gpu/drm/i915/display/intel_snps_phy.c

between commit:

  28adef861233c ("drm/i915/dg2: Print PHY name properly on calibration error")

from the drm-intel-fixes tree and commits:

  84073e568eec7 ("drm/i915/dg2: Print PHY name properly on calibration error")
  b4eb76d82a0ea ("drm/i915/dg2: Skip output init on PHY calibration failure")

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

[Used drm-intel version]

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[broonie]

Hi all,

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

  drivers/gpu/drm/i915/display/intel_bw.c

between commit:

  ec663bca9128f ("drm/i915: Fix bw atomic check when switching between SAGV vs. no SAGV")

from the drm-intel-fixes tree and commit:

  6d8ebef53c2cc ("drm/i915: Extract intel_bw_check_data_rate()")

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

(took the drm-intel version)

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/gpu/drm/i915/i915_reg.h

between commit:

  b3f74938d656 ("drm/i915/pmu: Use PM timestamp instead of RING TIMESTAMP for reference")

from the drm-intel-fixes tree and commit:

  22ba60f617bd ("drm/i915: Move [more] GT registers to their own header file")

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

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Mark Brown]

Hi all,

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

  drivers/gpu/drm/i915/intel_device_info.c

between commit:

  0f9ed3b2c9ec ("drm/i915/display/cnl+: Handle fused off DSC")

from the drm-intel-fixes tree and commit:

  a4d082fc194a ("drm/i915: rename/remove CNL registers")

from the drm-intel 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/i915/intel_device_info.c
index e0a10f36acc1,305facedd284..000000000000
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c

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

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 1584 bytes --]

Hi all,

On Tue, 30 Jun 2020 11:52:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
> 
>   drivers/gpu/drm/i915/gvt/handlers.c
> 
> between commit:
> 
>   fc1e3aa0337c ("drm/i915/gvt: Fix incorrect check of enabled bits in mask registers")
> 
> from the drm-intel-fixes tree and commit:
> 
>   5f4ae2704d59 ("drm/i915: Identify Cometlake platform")
> 
> from the drm-intel 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/i915/gvt/handlers.c
> index fadd2adb8030,26cae4846c82..000000000000
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@@ -1731,8 -1734,9 +1734,9 @@@ static int ring_mode_mmio_write(struct 
>   		return 0;
>   	}
>   
> - 	if (IS_COFFEELAKE(vgpu->gvt->gt->i915) &&
> + 	if ((IS_COFFEELAKE(vgpu->gvt->gt->i915) ||
> + 	     IS_COMETLAKE(vgpu->gvt->gt->i915)) &&
>  -	    data & _MASKED_BIT_ENABLE(2)) {
>  +	    IS_MASKED_BITS_ENABLED(data, 2)) {
>   		enter_failsafe_mode(vgpu, GVT_FAILSAFE_UNSUPPORTED_GUEST);
>   		return 0;
>   	}

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

-- 
Cheers,
Stephen Rothwell

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 1360 bytes --]

Hi all,

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

  drivers/gpu/drm/i915/gvt/handlers.c

between commit:

  fc1e3aa0337c ("drm/i915/gvt: Fix incorrect check of enabled bits in mask registers")

from the drm-intel-fixes tree and commit:

  5f4ae2704d59 ("drm/i915: Identify Cometlake platform")

from the drm-intel 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/i915/gvt/handlers.c
index fadd2adb8030,26cae4846c82..000000000000
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@@ -1731,8 -1734,9 +1734,9 @@@ static int ring_mode_mmio_write(struct 
  		return 0;
  	}
  
- 	if (IS_COFFEELAKE(vgpu->gvt->gt->i915) &&
+ 	if ((IS_COFFEELAKE(vgpu->gvt->gt->i915) ||
+ 	     IS_COMETLAKE(vgpu->gvt->gt->i915)) &&
 -	    data & _MASKED_BIT_ENABLE(2)) {
 +	    IS_MASKED_BITS_ENABLED(data, 2)) {
  		enter_failsafe_mode(vgpu, GVT_FAILSAFE_UNSUPPORTED_GUEST);
  		return 0;
  	}

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Rodrigo Vivi]

Hi Stephen,

On Fri, Mar 22, 2019 at 10:57:28AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drm-intel tree got a conflict in:
> 
>   drivers/gpu/drm/i915/gvt/mmio_context.c
> 
> between commit:
> 
>   1e8b15a1988e ("drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list")
> 
> from the drm-intel-fixes tree and commit:
> 
>   8a68d464366e ("drm/i915: Store the BIT(engine->id) as the engine's mask")
> 
> from the drm-intel 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.

I wonder how we could improve the situation here for drm-intel/drm-tip.
Because this wasn't a matter of not mentioning to upstream maintainer because
this was not sent up yet.

So I got this conflict after pulling gvt fixes to drm-intel-fixes
and conflict happened when reconstructing drm-intel. For us the
solution was easy because it was a matter of deciding for the -next
one.

And now it is recorded on our drm-rerere and nobody should face it again
here.

Maybe there is a way of reusing our drm-rerere somehow?

Please let me know if you have any ideas or suggestions.

Thanks,
Rodrigo.


> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/i915/gvt/mmio_context.c
> index 7902fb162d09,a00a807a1d55..000000000000
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> @@@ -73,71 -73,70 +73,71 @@@ static struct engine_mmio gen8_engine_m
>   };
>   
>   static struct engine_mmio gen9_engine_mmio_list[] __cacheline_aligned = {
> - 	{RCS, GFX_MODE_GEN7, 0xffff, false}, /* 0x229c */
> - 	{RCS, GEN9_CTX_PREEMPT_REG, 0x0, false}, /* 0x2248 */
> - 	{RCS, HWSTAM, 0x0, false}, /* 0x2098 */
> - 	{RCS, INSTPM, 0xffff, true}, /* 0x20c0 */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 0), 0, false}, /* 0x24d0 */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 1), 0, false}, /* 0x24d4 */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 2), 0, false}, /* 0x24d8 */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 3), 0, false}, /* 0x24dc */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 4), 0, false}, /* 0x24e0 */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 5), 0, false}, /* 0x24e4 */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 6), 0, false}, /* 0x24e8 */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 7), 0, false}, /* 0x24ec */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 8), 0, false}, /* 0x24f0 */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 9), 0, false}, /* 0x24f4 */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 10), 0, false}, /* 0x24f8 */
> - 	{RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 11), 0, false}, /* 0x24fc */
> - 	{RCS, CACHE_MODE_1, 0xffff, true}, /* 0x7004 */
> - 	{RCS, GEN7_GT_MODE, 0xffff, true}, /* 0x7008 */
> - 	{RCS, CACHE_MODE_0_GEN7, 0xffff, true}, /* 0x7000 */
> - 	{RCS, GEN7_COMMON_SLICE_CHICKEN1, 0xffff, true}, /* 0x7010 */
> - 	{RCS, HDC_CHICKEN0, 0xffff, true}, /* 0x7300 */
> - 	{RCS, VF_GUARDBAND, 0xffff, true}, /* 0x83a4 */
> - 
> - 	{RCS, GEN8_PRIVATE_PAT_LO, 0, false}, /* 0x40e0 */
> - 	{RCS, GEN8_PRIVATE_PAT_HI, 0, false}, /* 0x40e4 */
> - 	{RCS, GEN8_CS_CHICKEN1, 0xffff, true}, /* 0x2580 */
> - 	{RCS, COMMON_SLICE_CHICKEN2, 0xffff, true}, /* 0x7014 */
> - 	{RCS, GEN9_CS_DEBUG_MODE1, 0xffff, false}, /* 0x20ec */
> - 	{RCS, GEN8_L3SQCREG4, 0, false}, /* 0xb118 */
> - 	{RCS, GEN7_HALF_SLICE_CHICKEN1, 0xffff, true}, /* 0xe100 */
> - 	{RCS, HALF_SLICE_CHICKEN2, 0xffff, true}, /* 0xe180 */
> - 	{RCS, HALF_SLICE_CHICKEN3, 0xffff, true}, /* 0xe184 */
> - 	{RCS, GEN9_HALF_SLICE_CHICKEN5, 0xffff, true}, /* 0xe188 */
> - 	{RCS, GEN9_HALF_SLICE_CHICKEN7, 0xffff, true}, /* 0xe194 */
> - 	{RCS, GEN8_ROW_CHICKEN, 0xffff, true}, /* 0xe4f0 */
> - 	{RCS, TRVATTL3PTRDW(0), 0, false}, /* 0x4de0 */
> - 	{RCS, TRVATTL3PTRDW(1), 0, false}, /* 0x4de4 */
> - 	{RCS, TRNULLDETCT, 0, false}, /* 0x4de8 */
> - 	{RCS, TRINVTILEDETCT, 0, false}, /* 0x4dec */
> - 	{RCS, TRVADR, 0, false}, /* 0x4df0 */
> - 	{RCS, TRTTE, 0, false}, /* 0x4df4 */
> - 
> - 	{BCS, RING_GFX_MODE(BLT_RING_BASE), 0xffff, false}, /* 0x2229c */
> - 	{BCS, RING_MI_MODE(BLT_RING_BASE), 0xffff, false}, /* 0x2209c */
> - 	{BCS, RING_INSTPM(BLT_RING_BASE), 0xffff, false}, /* 0x220c0 */
> - 	{BCS, RING_HWSTAM(BLT_RING_BASE), 0x0, false}, /* 0x22098 */
> - 	{BCS, RING_EXCC(BLT_RING_BASE), 0x0, false}, /* 0x22028 */
> - 
> - 	{VCS2, RING_EXCC(GEN8_BSD2_RING_BASE), 0xffff, false}, /* 0x1c028 */
> - 
> - 	{VECS, RING_EXCC(VEBOX_RING_BASE), 0xffff, false}, /* 0x1a028 */
> - 
> - 	{RCS, GEN8_HDC_CHICKEN1, 0xffff, true}, /* 0x7304 */
> - 	{RCS, GEN9_CTX_PREEMPT_REG, 0x0, false}, /* 0x2248 */
> - 	{RCS, GEN7_UCGCTL4, 0x0, false}, /* 0x940c */
> - 	{RCS, GAMT_CHKN_BIT_REG, 0x0, false}, /* 0x4ab8 */
> - 
> - 	{RCS, GEN9_GAMT_ECO_REG_RW_IA, 0x0, false}, /* 0x4ab0 */
> - 	{RCS, GEN9_CSFE_CHICKEN1_RCS, 0xffff, false}, /* 0x20d4 */
> - 	{RCS, _MMIO(0x20D8), 0xffff, true}, /* 0x20d8 */
> - 
> - 	{RCS, GEN8_GARBCNTL, 0x0, false}, /* 0xb004 */
> - 	{RCS, GEN7_FF_THREAD_MODE, 0x0, false}, /* 0x20a0 */
> - 	{RCS, FF_SLICE_CS_CHICKEN2, 0xffff, false}, /* 0x20e4 */
> - 	{RCS, INVALID_MMIO_REG, 0, false } /* Terminated */
> + 	{RCS0, GFX_MODE_GEN7, 0xffff, false}, /* 0x229c */
> + 	{RCS0, GEN9_CTX_PREEMPT_REG, 0x0, false}, /* 0x2248 */
> + 	{RCS0, HWSTAM, 0x0, false}, /* 0x2098 */
> + 	{RCS0, INSTPM, 0xffff, true}, /* 0x20c0 */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 0), 0, false}, /* 0x24d0 */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 1), 0, false}, /* 0x24d4 */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 2), 0, false}, /* 0x24d8 */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 3), 0, false}, /* 0x24dc */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 4), 0, false}, /* 0x24e0 */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 5), 0, false}, /* 0x24e4 */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 6), 0, false}, /* 0x24e8 */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 7), 0, false}, /* 0x24ec */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 8), 0, false}, /* 0x24f0 */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 9), 0, false}, /* 0x24f4 */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 10), 0, false}, /* 0x24f8 */
> + 	{RCS0, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 11), 0, false}, /* 0x24fc */
> + 	{RCS0, CACHE_MODE_1, 0xffff, true}, /* 0x7004 */
> + 	{RCS0, GEN7_GT_MODE, 0xffff, true}, /* 0x7008 */
> + 	{RCS0, CACHE_MODE_0_GEN7, 0xffff, true}, /* 0x7000 */
> + 	{RCS0, GEN7_COMMON_SLICE_CHICKEN1, 0xffff, true}, /* 0x7010 */
> + 	{RCS0, HDC_CHICKEN0, 0xffff, true}, /* 0x7300 */
> + 	{RCS0, VF_GUARDBAND, 0xffff, true}, /* 0x83a4 */
> + 
> + 	{RCS0, GEN8_PRIVATE_PAT_LO, 0, false}, /* 0x40e0 */
> + 	{RCS0, GEN8_PRIVATE_PAT_HI, 0, false}, /* 0x40e4 */
> + 	{RCS0, GEN8_CS_CHICKEN1, 0xffff, true}, /* 0x2580 */
> + 	{RCS0, COMMON_SLICE_CHICKEN2, 0xffff, true}, /* 0x7014 */
> + 	{RCS0, GEN9_CS_DEBUG_MODE1, 0xffff, false}, /* 0x20ec */
> + 	{RCS0, GEN8_L3SQCREG4, 0, false}, /* 0xb118 */
> + 	{RCS0, GEN7_HALF_SLICE_CHICKEN1, 0xffff, true}, /* 0xe100 */
> + 	{RCS0, HALF_SLICE_CHICKEN2, 0xffff, true}, /* 0xe180 */
> + 	{RCS0, HALF_SLICE_CHICKEN3, 0xffff, true}, /* 0xe184 */
> + 	{RCS0, GEN9_HALF_SLICE_CHICKEN5, 0xffff, true}, /* 0xe188 */
> + 	{RCS0, GEN9_HALF_SLICE_CHICKEN7, 0xffff, true}, /* 0xe194 */
> + 	{RCS0, GEN8_ROW_CHICKEN, 0xffff, true}, /* 0xe4f0 */
> + 	{RCS0, TRVATTL3PTRDW(0), 0, false}, /* 0x4de0 */
> + 	{RCS0, TRVATTL3PTRDW(1), 0, false}, /* 0x4de4 */
> + 	{RCS0, TRNULLDETCT, 0, false}, /* 0x4de8 */
> + 	{RCS0, TRINVTILEDETCT, 0, false}, /* 0x4dec */
> + 	{RCS0, TRVADR, 0, false}, /* 0x4df0 */
> + 	{RCS0, TRTTE, 0, false}, /* 0x4df4 */
> + 
> + 	{BCS0, RING_GFX_MODE(BLT_RING_BASE), 0xffff, false}, /* 0x2229c */
> + 	{BCS0, RING_MI_MODE(BLT_RING_BASE), 0xffff, false}, /* 0x2209c */
> + 	{BCS0, RING_INSTPM(BLT_RING_BASE), 0xffff, false}, /* 0x220c0 */
> + 	{BCS0, RING_HWSTAM(BLT_RING_BASE), 0x0, false}, /* 0x22098 */
> + 	{BCS0, RING_EXCC(BLT_RING_BASE), 0x0, false}, /* 0x22028 */
> + 
> + 	{VCS1, RING_EXCC(GEN8_BSD2_RING_BASE), 0xffff, false}, /* 0x1c028 */
> + 
> + 	{VECS0, RING_EXCC(VEBOX_RING_BASE), 0xffff, false}, /* 0x1a028 */
> + 
> + 	{RCS0, GEN8_HDC_CHICKEN1, 0xffff, true}, /* 0x7304 */
> + 	{RCS0, GEN9_CTX_PREEMPT_REG, 0x0, false}, /* 0x2248 */
> + 	{RCS0, GEN7_UCGCTL4, 0x0, false}, /* 0x940c */
> + 	{RCS0, GAMT_CHKN_BIT_REG, 0x0, false}, /* 0x4ab8 */
> + 
> + 	{RCS0, GEN9_GAMT_ECO_REG_RW_IA, 0x0, false}, /* 0x4ab0 */
> + 	{RCS0, GEN9_CSFE_CHICKEN1_RCS, 0xffff, false}, /* 0x20d4 */
> ++	{RCS0, _MMIO(0x20D8), 0xffff, true}, /* 0x20d8 */
> + 
> + 	{RCS0, GEN8_GARBCNTL, 0x0, false}, /* 0xb004 */
> + 	{RCS0, GEN7_FF_THREAD_MODE, 0x0, false}, /* 0x20a0 */
> + 	{RCS0, FF_SLICE_CS_CHICKEN2, 0xffff, false}, /* 0x20e4 */
> + 	{RCS0, INVALID_MMIO_REG, 0, false } /* Terminated */
>   };
>   
>   static struct {



> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

On Wed, 24 Aug 2016, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
>   drivers/gpu/drm/i915/intel_display.c
>
> between commits from the drm-intel-fixes tree (some of which are
> cherry-picked from the drm-intel tree) and teh same and other commits
> from the drm-inte tree.  These are just going to cause new conflicts
> every time you touch this file again in either tree (which happens a
> lot :-().
>
> 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 only putting
> the fix patches into the drm-intel-fixes tree and then getting them
> into the drm-intel tree by merging the -fixes tree instead of
> cherry-picking them the other way.

We used to do that, but switched to the current model instead. The main
reason was that we wanted our development branch to always get the fixes
first, without delay. We have several committers, and we want to make it
efficient and hassle free for them to get fixes applied.

The drm-intel tree is a fast moving target. If we fix something in
-fixes, there's no guarantee the fix applies to -next. It is more
important that we get the fix in -next, and all future kernels. If the
fix is important for current and stable kernels, we can do the
backport. This way, we can always resolve conflicts with the code in
-next, and be sure it contains all the fixes. If only -fixes had the
fixes, we'd have nightmare conflict resolutions trying to ensure none of
the fixes get dropped while merging.

Finally, you don't always know in advance whether the patch should be
applied to -next or -fixes. We'd end up with cherry-picks like this
anyway. Now we can do QA on the fixes in -next, and choose the ones to
backport.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel