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

2020-07-05 Thread Stephen Rothwell 
Hi all,

On Tue, 30 Jun 2020 11:52:02 +1000 Stephen Rothwell  
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..
> --- 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


pgpC3peoNAXK7.pgp
Description: OpenPGP digital signature
___
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

2020-03-19 Thread Stephen Rothwell 
Hi all,

On Wed, 11 Mar 2020 13:36:35 +1100 Stephen Rothwell  
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..
> --- 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_lock);
>  -
> + drm_WARN(>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(>lock);
>  +idr_remove(>vgpu_idr, vgpu->id);
>  +mutex_unlock(>lock);
>  +
>  +mutex_lock(>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


pgpTZhbgqZRPF.pgp
Description: OpenPGP digital signature
___
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

2019-03-31 Thread Stephen Rothwell 
Hi all,

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

On Fri, 22 Mar 2019 10:57:28 +1100 Stephen Rothwell  
wrote:
>
> 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.
> 
> diff --cc drivers/gpu/drm/i915/gvt/mmio_context.c
> index 7902fb162d09,a00a807a1d55..
> --- 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, 0x, false}, /* 0x229c */
> - {RCS, GEN9_CTX_PREEMPT_REG, 0x0, false}, /* 0x2248 */
> - {RCS, HWSTAM, 0x0, false}, /* 0x2098 */
> - {RCS, INSTPM, 0x, 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, 0x, true}, /* 0x7004 */
> - {RCS, GEN7_GT_MODE, 0x, true}, /* 0x7008 */
> - {RCS, CACHE_MODE_0_GEN7, 0x, true}, /* 0x7000 */
> - {RCS, GEN7_COMMON_SLICE_CHICKEN1, 0x, true}, /* 0x7010 */
> - {RCS, HDC_CHICKEN0, 0x, true}, /* 0x7300 */
> - {RCS, VF_GUARDBAND, 0x, true}, /* 0x83a4 */
> - 
> - {RCS, GEN8_PRIVATE_PAT_LO, 0, false}, /* 0x40e0 */
> - {RCS, GEN8_PRIVATE_PAT_HI, 0, false}, /* 0x40e4 */
> - {RCS, GEN8_CS_CHICKEN1, 0x, true}, /* 0x2580 */
> - {RCS, COMMON_SLICE_CHICKEN2, 0x, true}, /* 0x7014 */
> - {RCS, GEN9_CS_DEBUG_MODE1, 0x, false}, /* 0x20ec */
> - {RCS, GEN8_L3SQCREG4, 0, false}, /* 0xb118 */
> - {RCS, GEN7_HALF_SLICE_CHICKEN1, 0x, true}, /* 0xe100 */
> - {RCS, HALF_SLICE_CHICKEN2, 0x, true}, /* 0xe180 */
> - {RCS, HALF_SLICE_CHICKEN3, 0x, true}, /* 0xe184 */
> - {RCS, GEN9_HALF_SLICE_CHICKEN5, 0x, true}, /* 0xe188 */
> - {RCS, GEN9_HALF_SLICE_CHICKEN7, 0x, true}, /* 0xe194 */
> - {RCS, GEN8_ROW_CHICKEN, 0x, 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), 0x, false}, /* 0x2229c */
> - {BCS, RING_MI_MODE(BLT_RING_BASE), 0x, false}, /* 0x2209c */
> - {BCS, RING_INSTPM(BLT_RING_BASE), 0x, 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), 0x, false}, /* 0x1c028 */
> - 
> - {VECS, RING_EXCC(VEBOX_RING_BASE), 0x, false}, /* 0x1a028 */
> - 
> - {RCS, GEN8_HDC_CHICKEN1, 0x, 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, 0x, false}, /* 0x20d4 */
> - {RCS, _MMIO(0x20D8), 0x, true}, /* 0x20d8 */
> - 
> - {RCS, GEN8_GARBCNTL, 0x0, false}, /* 0xb004 */
> - {RCS, GEN7_FF_THREAD_MODE, 0x0, false}, /* 0x20a0 */
> -

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

2019-03-21 Thread 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..
> --- 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, 0x, false}, /* 0x229c */
> - {RCS, GEN9_CTX_PREEMPT_REG, 0x0, false}, /* 0x2248 */
> - {RCS, HWSTAM, 0x0, false}, /* 0x2098 */
> - {RCS, INSTPM, 0x, 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, 0x, true}, /* 0x7004 */
> - {RCS, GEN7_GT_MODE, 0x, true}, /* 0x7008 */
> - {RCS, CACHE_MODE_0_GEN7, 0x, true}, /* 0x7000 */
> - {RCS, GEN7_COMMON_SLICE_CHICKEN1, 0x, true}, /* 0x7010 */
> - {RCS, HDC_CHICKEN0, 0x, true}, /* 0x7300 */
> - {RCS, VF_GUARDBAND, 0x, true}, /* 0x83a4 */
> - 
> - {RCS, GEN8_PRIVATE_PAT_LO, 0, false}, /* 0x40e0 */
> - {RCS, GEN8_PRIVATE_PAT_HI, 0, false}, /* 0x40e4 */
> - {RCS, GEN8_CS_CHICKEN1, 0x, true}, /* 0x2580 */
> - {RCS, COMMON_SLICE_CHICKEN2, 0x, true}, /* 0x7014 */
> - {RCS, GEN9_CS_DEBUG_MODE1, 0x, false}, /* 0x20ec */
> - {RCS, GEN8_L3SQCREG4, 0, false}, /* 0xb118 */
> - {RCS, GEN7_HALF_SLICE_CHICKEN1, 0x, true}, /* 0xe100 */
> - {RCS, HALF_SLICE_CHICKEN2, 0x, true}, /* 0xe180 */
> - {RCS, HALF_SLICE_CHICKEN3, 0x, true}, /* 0xe184 */
> - {RCS, GEN9_HALF_SLICE_CHICKEN5, 0x, true}, /* 0xe188 */
> - {RCS, GEN9_HALF_SLICE_CHICKEN7, 0x, true}, /* 0xe194 */
> - {RCS, GEN8_ROW_CHICKEN, 0x, 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), 0x, false}, /* 0x2229c */
> - {BCS, RING_MI_MODE(BLT_RING_BASE), 0x, false}, /* 0x2209c */
> - {BCS, RING_INSTPM(BLT_RING_BASE), 0x, 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), 0x, false}, /* 0x1c028 */
> - 
> - {VECS, RING_EXCC(VEBOX_RING_BASE),

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

2017-10-17 Thread Mark Brown 
On Tue, Oct 17, 2017 at 10:11:53AM +0200, Arnd Bergmann wrote:

> This merge seems fine, but it seems there was another merge
> against the akpm tree that introduced a build error by reintroducing
> the spin_lock_irqsave() without restoring the local variable:

> drivers/gpu/drm/i915/i915_gem.c: In function 'nop_submit_request':
> drivers/gpu/drm/i915/i915_gem.c:3092:54: error: 'flags' undeclared
> (first use in this function); did you mean 'class'?

> I'll send my local build fix, which may or may not be the intended
> behavior but gets it to compile.

Bother, that was actually an automated merge git did.


signature.asc
Description: PGP signature
___
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

2017-10-17 Thread Arnd Bergmann 
On Mon, Oct 16, 2017 at 1:35 PM, Mark Brown  wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
>   drivers/gpu/drm/i915/i915_gem.c
>
> between commit:
>
>   b85577b72837e ("drm/i915: Order two completing nop_submit_request")
>
> from the drm-intel-fixes tree and commit:
>
>   5d031f4e1618b ("drm/i915: Stop asserting on set-wedged vs 
> nop_submit_request ordering")
>
> 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.

This merge seems fine, but it seems there was another merge
against the akpm tree that introduced a build error by reintroducing
the spin_lock_irqsave() without restoring the local variable:

drivers/gpu/drm/i915/i915_gem.c: In function 'nop_submit_request':
drivers/gpu/drm/i915/i915_gem.c:3092:54: error: 'flags' undeclared
(first use in this function); did you mean 'class'?

I'll send my local build fix, which may or may not be the intended
behavior but gets it to compile.

  Arnd
___
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

2016-08-24 Thread Jani Nikula 
On Wed, 24 Aug 2016, Stephen Rothwell  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
___
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

2015-09-24 Thread Stephen Rothwell 
Hi Jani,

On Thu, 24 Sep 2015 11:57:05 +0300 Jani Nikula  
wrote:
>
> That was the right thing to do.
> 
> The former commit is headed for v4.3, and there will have to be another
> version of it for -next. This will cause you another conflict, and you
> should resolve it with the same approach.

OK, thanks.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://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

2015-09-24 Thread Jani Nikula 
On Thu, 24 Sep 2015, Stephen Rothwell  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 commit:
>
>   721a09f7393d ("drm/i915: Add primary plane to mask if it's visible")
>
> from the drm-intel-fixes tree and commit:
>
>   f9cd7b881a04 ("drm/i915: Move sprite/cursor plane disable to 
> intel_sanitize_crtc()")
>
> from the drm-intel tree.
>
> I fixed it up (I have no idea what do to here, so I just used the version
> from the drm-intel tree) and can carry the fix as necessary (no action
> is required - unless there is a better fix).

That was the right thing to do.

The former commit is headed for v4.3, and there will have to be another
version of it for -next. This will cause you another conflict, and you
should resolve it with the same approach.

Thanks,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://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

2015-07-14 Thread Daniel Vetter 
On Tue, Jul 14, 2015 at 12:11:12PM +1000, Stephen Rothwell 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 commit:
 
   8aa3053bf731 (drm/i915: fix oops in primary_check_plane)
 
 from the drm-intel-fixes tree and commit:
 
   da20eabd2c69 (drm/i915: Split plane updates of crtc-atomic into a helper, 
 v2.)
 
 from the drm-intel tree.
 
 I fixed it up (but it probably needs more - see below) and can carry
 the fix as necessary.
 
 Daniel, can you please merge your fixes branch into your main branch
 (maybe after Linus has merged it) and fix these conflicts correctly as
 these conflicts tend to go on and on as the files get changed.

Well the problem is that they indeed go on and on and we still change them
so they resurface all the time. I've done a few backmerges in my next
branch already, I plan to do the next backmerge somewhen this week.

Sorry about all the pain this is causing.
-Daniel

 
 -- 
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
 
 diff --cc drivers/gpu/drm/i915/intel_display.c
 index 85ac6d85dc39,00c60c1c5162..
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@@ -4851,25 -4802,13 +4802,16 @@@ static void intel_crtc_disable_planes(s
   {
   struct drm_device *dev = crtc-dev;
   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 - struct intel_plane *intel_plane;
 + struct drm_plane *p;
   int pipe = intel_crtc-pipe;
   
  +if (!intel_crtc-active)
  +return;
  +
 - intel_crtc_wait_for_pending_flips(crtc);
 - 
 - intel_pre_disable_primary(crtc);
 - 
   intel_crtc_dpms_overlay_disable(intel_crtc);
 - for_each_intel_plane(dev, intel_plane) {
 - if (intel_plane-pipe == pipe) {
 - struct drm_crtc *from = intel_plane-base.crtc;
   
 - intel_plane-disable_plane(intel_plane-base,
 -from ?: crtc, true);
 - }
 - }
 + drm_for_each_plane_mask(p, dev, plane_mask)
 + to_intel_plane(p)-disable_plane(p, crtc);
   
   /*
* FIXME: Once we grow proper nuclear flip support out of this we need
 @@@ -13382,47 -13751,11 +13757,14 @@@ static void intel_begin_crtc_commit(str
   struct drm_device *dev = crtc-dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 - struct intel_plane *intel_plane;
 - struct drm_plane *p;
 - unsigned fb_bits = 0;
 - 
 - /* Track fb's for any planes being disabled */
 - list_for_each_entry(p, dev-mode_config.plane_list, head) {
 - intel_plane = to_intel_plane(p);
 - 
 - if (intel_crtc-atomic.disabled_planes 
 - (1  drm_plane_index(p))) {
 - switch (p-type) {
 - case DRM_PLANE_TYPE_PRIMARY:
 - fb_bits = 
 INTEL_FRONTBUFFER_PRIMARY(intel_plane-pipe);
 - break;
 - case DRM_PLANE_TYPE_CURSOR:
 - fb_bits = 
 INTEL_FRONTBUFFER_CURSOR(intel_plane-pipe);
 - break;
 - case DRM_PLANE_TYPE_OVERLAY:
 - fb_bits = 
 INTEL_FRONTBUFFER_SPRITE(intel_plane-pipe);
 - break;
 - }
   
 - mutex_lock(dev-struct_mutex);
 - i915_gem_track_fb(intel_fb_obj(p-fb), NULL, fb_bits);
 - mutex_unlock(dev-struct_mutex);
 - }
 - }
 - 
 - if (intel_crtc-atomic.wait_for_flips)
 - intel_crtc_wait_for_pending_flips(crtc);
 - 
 - if (intel_crtc-atomic.disable_fbc)
 - intel_fbc_disable(dev);
 + if (!needs_modeset(crtc-state))
 + intel_pre_plane_update(intel_crtc);
   
  +if (intel_crtc-atomic.disable_ips)
  +hsw_disable_ips(intel_crtc);
  +
 - if (intel_crtc-atomic.pre_disable_primary)
 - intel_pre_disable_primary(crtc);
 - 
 - if (intel_crtc-atomic.update_wm)
 + if (intel_crtc-atomic.update_wm_pre)
   intel_update_watermarks(crtc);
   
   intel_runtime_pm_get(dev_priv);



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://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

2013-12-01 Thread Stephen Rothwell 
On Mon, 2 Dec 2013 12:04:37 +1100 Stephen Rothwell s...@canb.auug.org.au 
wrote:

 Today's linux-next merge of the drm-intel tree got a conflict in
 drivers/gpu/drm/i915/intel_display.c between commit a1216444283e
 (drm/i915: use the correct force_wake function at the PC8 code) from
 the drm-intel-fixes tree and commit c8d9a5905e45 (drm/i915: Add power
 well arguments to force wake routines) from the drm-intel tree.
 
 I fixed it up (I just used the drm-intel-fixes version) and can carry the
 fix as necessary (no action is required).

Actually, I ended up doing the below.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_display.c
index 080f6fd4e839,0332d7ca892d..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -6402,7 -6583,7 +6583,7 @@@ static void hsw_restore_lcpll(struct dr
  
/* Make sure we're not on PC8 state before disabling PC8, otherwise
 * we'll hang the machine! */
-   gen6_gt_force_wake_get(dev_priv);
 -  dev_priv-uncore.funcs.force_wake_get(dev_priv, FORCEWAKE_ALL);
++  gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
  
if (val  LCPLL_POWER_DOWN_ALLOW) {
val = ~LCPLL_POWER_DOWN_ALLOW;
@@@ -6436,7 -6617,7 +6617,7 @@@
DRM_ERROR(Switching back to LCPLL failed\n);
}
  
-   gen6_gt_force_wake_put(dev_priv);
 -  dev_priv-uncore.funcs.force_wake_put(dev_priv, FORCEWAKE_ALL);
++  gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
  }
  
  void hsw_enable_pc8_work(struct work_struct *__work)


pgpMSlb10HXJL.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx