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

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

[Daniel Vetter]

On Wed, Apr 30, 2014 at 7:38 AM, Jani Nikula <jani.nikula@intel.com> wrote:
> On Wed, 30 Apr 2014, 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/i915_gem_gtt.c between commitcfa7c862982b
>> ("drm/i915: Sanitize the enable_ppgtt module option once") from the
>> drm-intel-fixes tree tree and commit 5db6c735ead5 ("drm/i915: dmesg
>> output for VT-d testing") from the drm-intel tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> Hi Stephen -
>
> [off-list to not confuse everyone; I'll confuse just you instead!]

Re-adding linux-next since it might be interesting for others.

> IIUC you pull both our for-linux-next-fixes and for-linux-next
> branches. There's bound to be occasional conflicts, as the former is
> based on Linus' tree with fixes for -rc and -stable, and the latter
> contains the new development for -next.
>
> Now, every time Daniel or I push to either one, we reconstruct our
> drm-intel-nightly branch [1] which merges both (and then some). Which
> means we've already resolved any conflicts once (and have some tooling
> to share the conflict resolutions between ourselves). If you look at the
> merge commits there, you'll see how we have resolved the conflicts.
>
> As far as I can tell you and the other linux-next maintainers have done
> a good job resolving our conflicts for -next (also this time), but I am
> wondering whether that's a burden that could be reduced. At the very
> least there's our -nightly branch you can look at if in doubt.
>
> Thoughts?

On that topic we have a rerere-cache branch in the drm-intel.git repo
which contains the .git/rr-cache directory plus any manual fixup
patches we need. That might be easier for peeking merge resolutions.

Another issue I wonder about is topic branches. We've started to use
them a bit more the past releases, but most of them are fairly
temporary in nature. I.e. I pull in reviewed patches into a new topic/
branch, let it soak for a bit and then either send the pull request to
Dave directly or merge it into drm-intel-next-queued. topic/core-stuff
is the only stable topic branch (contains random non-i915 drm patches
I pick up) so would imo make sense to add it to linux-next. But I'm
not sure about the others.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Stephen Rothwell]

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.

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

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

[Stephen Rothwell]

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.

-- 
Cheers,
Stephen Rothwell

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

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

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

[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

[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

[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

[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

[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

[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

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