Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
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
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->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 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
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
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), 0xf
Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
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
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
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
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
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
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
On Mon, 2 Dec 2013 12:04:37 +1100 Stephen Rothwell 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