* linux-next: manual merge of the drm-intel tree with Linus' tree
@ 2022-11-13 23:23 Stephen Rothwell
2022-11-14 8:19 ` Hans de Goede
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2022-11-13 23:23 UTC (permalink / raw)
To: Daniel Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi
Cc: Intel Graphics, DRI, Hans de Goede, Jani Nikula,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_backlight.c
between commit:
b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
from Linus' tree and commit:
801543b2593b ("drm/i915: stop including i915_irq.h from i915_trace.h")
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/display/intel_backlight.c
index beba39a38c87,0438071f58cf..000000000000
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@@ -8,8 -8,7 +8,9 @@@
#include <linux/pwm.h>
#include <linux/string_helpers.h>
+#include <acpi/video.h>
+
+ #include "i915_reg.h"
#include "intel_backlight.h"
#include "intel_backlight_regs.h"
#include "intel_connector.h"
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: linux-next: manual merge of the drm-intel tree with Linus' tree
2022-11-13 23:23 linux-next: manual merge of the drm-intel tree with Linus' tree Stephen Rothwell
@ 2022-11-14 8:19 ` Hans de Goede
2022-11-14 10:10 ` Jani Nikula
0 siblings, 1 reply; 7+ messages in thread
From: Hans de Goede @ 2022-11-14 8:19 UTC (permalink / raw)
To: Stephen Rothwell, Daniel Vetter, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi
Cc: Intel Graphics, DRI, Jani Nikula, Linux Kernel Mailing List,
Linux Next Mailing List
Hi,
On 11/14/22 00:23, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/display/intel_backlight.c
>
> between commit:
>
> b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
>
> from Linus' tree and commit:
>
> 801543b2593b ("drm/i915: stop including i915_irq.h from i915_trace.h")
>
> from the drm-intel tree.
This is weird, because the:
b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
commit is in 6.1-rc1, so there can only be a conflict it 6.1-rc1 has not
been back-merged into drm-intel yet ?
Regards,
Hans
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: linux-next: manual merge of the drm-intel tree with Linus' tree
2022-11-14 8:19 ` Hans de Goede
@ 2022-11-14 10:10 ` Jani Nikula
2022-11-14 10:35 ` Hans de Goede
0 siblings, 1 reply; 7+ messages in thread
From: Jani Nikula @ 2022-11-14 10:10 UTC (permalink / raw)
To: Hans de Goede, Stephen Rothwell, Daniel Vetter, Joonas Lahtinen,
Rodrigo Vivi
Cc: Intel Graphics, DRI, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, 14 Nov 2022, Hans de Goede <hdegoede@redhat•com> wrote:
> Hi,
>
> On 11/14/22 00:23, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the drm-intel tree got a conflict in:
>>
>> drivers/gpu/drm/i915/display/intel_backlight.c
>>
>> between commit:
>>
>> b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
>>
>> from Linus' tree and commit:
>>
>> 801543b2593b ("drm/i915: stop including i915_irq.h from i915_trace.h")
>>
>> from the drm-intel tree.
>
> This is weird, because the:
>
> b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
>
> commit is in 6.1-rc1, so there can only be a conflict it 6.1-rc1 has not
> been back-merged into drm-intel yet ?
That's the reason it *is* a conflict, right?
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: linux-next: manual merge of the drm-intel tree with Linus' tree
2022-11-14 10:10 ` Jani Nikula
@ 2022-11-14 10:35 ` Hans de Goede
2022-11-14 11:02 ` Jani Nikula
0 siblings, 1 reply; 7+ messages in thread
From: Hans de Goede @ 2022-11-14 10:35 UTC (permalink / raw)
To: Jani Nikula, Stephen Rothwell, Daniel Vetter, Joonas Lahtinen,
Rodrigo Vivi
Cc: Intel Graphics, DRI, Linux Kernel Mailing List,
Linux Next Mailing List
Hi,
On 11/14/22 11:10, Jani Nikula wrote:
> On Mon, 14 Nov 2022, Hans de Goede <hdegoede@redhat•com> wrote:
>> Hi,
>>
>> On 11/14/22 00:23, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the drm-intel tree got a conflict in:
>>>
>>> drivers/gpu/drm/i915/display/intel_backlight.c
>>>
>>> between commit:
>>>
>>> b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
>>>
>>> from Linus' tree and commit:
>>>
>>> 801543b2593b ("drm/i915: stop including i915_irq.h from i915_trace.h")
>>>
>>> from the drm-intel tree.
>>
>> This is weird, because the:
>>
>> b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
>>
>> commit is in 6.1-rc1, so there can only be a conflict it 6.1-rc1 has not
>> been back-merged into drm-intel yet ?
>
> That's the reason it *is* a conflict, right?
Right what I was trying to say is that I am surprised that 6.1-rc1 has not
been back-merged into drm-intel yet even though it has been released
4 weeks ago.
I thought it was more or less standard process to backmerge rc1 soon after
it is released ?
Regards,
Hans
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: linux-next: manual merge of the drm-intel tree with Linus' tree
2022-11-14 10:35 ` Hans de Goede
@ 2022-11-14 11:02 ` Jani Nikula
2022-11-14 19:29 ` [Intel-gfx] " Rodrigo Vivi
0 siblings, 1 reply; 7+ messages in thread
From: Jani Nikula @ 2022-11-14 11:02 UTC (permalink / raw)
To: Hans de Goede, Stephen Rothwell, Daniel Vetter, Joonas Lahtinen,
Rodrigo Vivi
Cc: Intel Graphics, DRI, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, 14 Nov 2022, Hans de Goede <hdegoede@redhat•com> wrote:
> Hi,
>
> On 11/14/22 11:10, Jani Nikula wrote:
>> On Mon, 14 Nov 2022, Hans de Goede <hdegoede@redhat•com> wrote:
>>> Hi,
>>>
>>> On 11/14/22 00:23, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Today's linux-next merge of the drm-intel tree got a conflict in:
>>>>
>>>> drivers/gpu/drm/i915/display/intel_backlight.c
>>>>
>>>> between commit:
>>>>
>>>> b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
>>>>
>>>> from Linus' tree and commit:
>>>>
>>>> 801543b2593b ("drm/i915: stop including i915_irq.h from i915_trace.h")
>>>>
>>>> from the drm-intel tree.
>>>
>>> This is weird, because the:
>>>
>>> b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
>>>
>>> commit is in 6.1-rc1, so there can only be a conflict it 6.1-rc1 has not
>>> been back-merged into drm-intel yet ?
>>
>> That's the reason it *is* a conflict, right?
>
> Right what I was trying to say is that I am surprised that 6.1-rc1 has not
> been back-merged into drm-intel yet even though it has been released
> 4 weeks ago.
Right, -ENOCOFFEE at my end.
> I thought it was more or less standard process to backmerge rc1 soon after
> it is released ?
The delay may be because v6.1-rc1 brought in more regressions for us
than any other -rc1 in recent memory. Our CI's been suffering, and our
folks have been spending a lot of time debugging, bisecting and
reporting. (And before you ask, yes, we're going to be more proactive in
reporting issues we find in linux-next.)
That said, Rodrigo's been in charge of drm-intel-next this cycle, maybe
it's time to backmerge drm-next?
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree
2022-11-14 11:02 ` Jani Nikula
@ 2022-11-14 19:29 ` Rodrigo Vivi
0 siblings, 0 replies; 7+ messages in thread
From: Rodrigo Vivi @ 2022-11-14 19:29 UTC (permalink / raw)
To: Jani Nikula
Cc: Hans de Goede, Stephen Rothwell, Daniel Vetter, Joonas Lahtinen,
Intel Graphics, Linux Next Mailing List,
Linux Kernel Mailing List, DRI
On Mon, Nov 14, 2022 at 01:02:46PM +0200, Jani Nikula wrote:
> On Mon, 14 Nov 2022, Hans de Goede <hdegoede@redhat•com> wrote:
> > Hi,
> >
> > On 11/14/22 11:10, Jani Nikula wrote:
> >> On Mon, 14 Nov 2022, Hans de Goede <hdegoede@redhat•com> wrote:
> >>> Hi,
> >>>
> >>> On 11/14/22 00:23, Stephen Rothwell wrote:
> >>>> Hi all,
> >>>>
> >>>> Today's linux-next merge of the drm-intel tree got a conflict in:
> >>>>
> >>>> drivers/gpu/drm/i915/display/intel_backlight.c
> >>>>
> >>>> between commit:
> >>>>
> >>>> b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
> >>>>
> >>>> from Linus' tree and commit:
> >>>>
> >>>> 801543b2593b ("drm/i915: stop including i915_irq.h from i915_trace.h")
> >>>>
> >>>> from the drm-intel tree.
> >>>
> >>> This is weird, because the:
> >>>
> >>> b1d36e73cc1c ("drm/i915: Don't register backlight when another backlight should be used (v2)")
> >>>
> >>> commit is in 6.1-rc1, so there can only be a conflict it 6.1-rc1 has not
> >>> been back-merged into drm-intel yet ?
> >>
> >> That's the reason it *is* a conflict, right?
> >
> > Right what I was trying to say is that I am surprised that 6.1-rc1 has not
> > been back-merged into drm-intel yet even though it has been released
> > 4 weeks ago.
>
> Right, -ENOCOFFEE at my end.
>
> > I thought it was more or less standard process to backmerge rc1 soon after
> > it is released ?
>
> The delay may be because v6.1-rc1 brought in more regressions for us
> than any other -rc1 in recent memory. Our CI's been suffering, and our
> folks have been spending a lot of time debugging, bisecting and
> reporting. (And before you ask, yes, we're going to be more proactive in
> reporting issues we find in linux-next.)
>
> That said, Rodrigo's been in charge of drm-intel-next this cycle, maybe
> it's time to backmerge drm-next?
yeap, I'm on it...
>
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 7+ messages in thread
* linux-next: manual merge of the drm-intel tree with Linus' tree
@ 2018-03-22 2:21 Stephen Rothwell
2018-03-23 0:50 ` Stephen Rothwell
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2018-03-22 2:21 UTC (permalink / raw)
To: Daniel Vetter, Intel Graphics, DRI
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3594 bytes --]
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/gvt/scheduler.c
between commit:
fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
from Linus' tree and commit:
b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.")
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/scheduler.c
index 068126404151,a55b4975c154..000000000000
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@@ -52,54 -52,29 +52,77 @@@ static void set_context_pdp_root_pointe
pdp_pair[i].val = pdp[7 - i];
}
+/*
+ * when populating shadow ctx from guest, we should not overrride oa related
+ * registers, so that they will not be overlapped by guest oa configs. Thus
+ * made it possible to capture oa data from host for both host and guests.
+ */
+static void sr_oa_regs(struct intel_vgpu_workload *workload,
+ u32 *reg_state, bool save)
+{
+ struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
+ u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
+ u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
+ int i = 0;
+ u32 flex_mmio[] = {
+ i915_mmio_reg_offset(EU_PERF_CNTL0),
+ i915_mmio_reg_offset(EU_PERF_CNTL1),
+ i915_mmio_reg_offset(EU_PERF_CNTL2),
+ i915_mmio_reg_offset(EU_PERF_CNTL3),
+ i915_mmio_reg_offset(EU_PERF_CNTL4),
+ i915_mmio_reg_offset(EU_PERF_CNTL5),
+ i915_mmio_reg_offset(EU_PERF_CNTL6),
+ };
+
+ if (!workload || !reg_state || workload->ring_id != RCS)
+ return;
+
+ if (save) {
+ workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
+
+ for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
+ u32 state_offset = ctx_flexeu0 + i * 2;
+
+ workload->flex_mmio[i] = reg_state[state_offset + 1];
+ }
+ } else {
+ reg_state[ctx_oactxctrl] =
+ i915_mmio_reg_offset(GEN8_OACTXCONTROL);
+ reg_state[ctx_oactxctrl + 1] = workload->oactxctrl;
+
+ for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
+ u32 state_offset = ctx_flexeu0 + i * 2;
+ u32 mmio = flex_mmio[i];
+
+ reg_state[state_offset] = mmio;
+ reg_state[state_offset + 1] = workload->flex_mmio[i];
+ }
+ }
+}
+
+ static void update_shadow_pdps(struct intel_vgpu_workload *workload)
+ {
+ struct intel_vgpu *vgpu = workload->vgpu;
+ int ring_id = workload->ring_id;
+ struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
+ struct drm_i915_gem_object *ctx_obj =
+ shadow_ctx->engine[ring_id].state->obj;
+ struct execlist_ring_context *shadow_ring_context;
+ struct page *page;
+
+ if (WARN_ON(!workload->shadow_mm))
+ return;
+
+ if (WARN_ON(!atomic_read(&workload->shadow_mm->pincount)))
+ return;
+
+ page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
+ shadow_ring_context = kmap(page);
+ set_context_pdp_root_pointer(shadow_ring_context,
+ (void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
+ kunmap(page);
+ }
+
static int populate_shadow_context(struct intel_vgpu_workload *workload)
{
struct intel_vgpu *vgpu = workload->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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: linux-next: manual merge of the drm-intel tree with Linus' tree
2018-03-22 2:21 Stephen Rothwell
@ 2018-03-23 0:50 ` Stephen Rothwell
2018-03-23 14:16 ` [Intel-gfx] " Joonas Lahtinen
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2018-03-23 0:50 UTC (permalink / raw)
To: DRI, Dave Airlie
Cc: Daniel Vetter, Intel Graphics, Linux Kernel Mailing List,
Linux-Next Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3992 bytes --]
Hi all,
On Thu, 22 Mar 2018 13:21:29 +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/scheduler.c
>
> between commit:
>
> fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
>
> from Linus' tree and commit:
>
> b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.")
>
> 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/scheduler.c
> index 068126404151,a55b4975c154..000000000000
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@@ -52,54 -52,29 +52,77 @@@ static void set_context_pdp_root_pointe
> pdp_pair[i].val = pdp[7 - i];
> }
>
> +/*
> + * when populating shadow ctx from guest, we should not overrride oa related
> + * registers, so that they will not be overlapped by guest oa configs. Thus
> + * made it possible to capture oa data from host for both host and guests.
> + */
> +static void sr_oa_regs(struct intel_vgpu_workload *workload,
> + u32 *reg_state, bool save)
> +{
> + struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> + u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> + u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> + int i = 0;
> + u32 flex_mmio[] = {
> + i915_mmio_reg_offset(EU_PERF_CNTL0),
> + i915_mmio_reg_offset(EU_PERF_CNTL1),
> + i915_mmio_reg_offset(EU_PERF_CNTL2),
> + i915_mmio_reg_offset(EU_PERF_CNTL3),
> + i915_mmio_reg_offset(EU_PERF_CNTL4),
> + i915_mmio_reg_offset(EU_PERF_CNTL5),
> + i915_mmio_reg_offset(EU_PERF_CNTL6),
> + };
> +
> + if (!workload || !reg_state || workload->ring_id != RCS)
> + return;
> +
> + if (save) {
> + workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
> +
> + for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
> + u32 state_offset = ctx_flexeu0 + i * 2;
> +
> + workload->flex_mmio[i] = reg_state[state_offset + 1];
> + }
> + } else {
> + reg_state[ctx_oactxctrl] =
> + i915_mmio_reg_offset(GEN8_OACTXCONTROL);
> + reg_state[ctx_oactxctrl + 1] = workload->oactxctrl;
> +
> + for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
> + u32 state_offset = ctx_flexeu0 + i * 2;
> + u32 mmio = flex_mmio[i];
> +
> + reg_state[state_offset] = mmio;
> + reg_state[state_offset + 1] = workload->flex_mmio[i];
> + }
> + }
> +}
> +
> + static void update_shadow_pdps(struct intel_vgpu_workload *workload)
> + {
> + struct intel_vgpu *vgpu = workload->vgpu;
> + int ring_id = workload->ring_id;
> + struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
> + struct drm_i915_gem_object *ctx_obj =
> + shadow_ctx->engine[ring_id].state->obj;
> + struct execlist_ring_context *shadow_ring_context;
> + struct page *page;
> +
> + if (WARN_ON(!workload->shadow_mm))
> + return;
> +
> + if (WARN_ON(!atomic_read(&workload->shadow_mm->pincount)))
> + return;
> +
> + page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
> + shadow_ring_context = kmap(page);
> + set_context_pdp_root_pointer(shadow_ring_context,
> + (void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
> + kunmap(page);
> + }
> +
> static int populate_shadow_context(struct intel_vgpu_workload *workload)
> {
> struct intel_vgpu *vgpu = workload->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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree
2018-03-23 0:50 ` Stephen Rothwell
@ 2018-03-23 14:16 ` Joonas Lahtinen
0 siblings, 0 replies; 7+ messages in thread
From: Joonas Lahtinen @ 2018-03-23 14:16 UTC (permalink / raw)
To: DRI, Dave Airlie, Stephen Rothwell
Cc: Daniel Vetter, Intel Graphics, Linux-Next Mailing List,
Linux Kernel Mailing List
Quoting Stephen Rothwell (2018-03-23 02:50:18)
> Hi all,
>
> On Thu, 22 Mar 2018 13:21:29 +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/scheduler.c
> >
> > between commit:
> >
> > fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
> >
> > from Linus' tree and commit:
> >
> > b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.")
> >
> > 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.
Hi Stephen,
Thanks for solving this, the resolution is correct.
You may want to replace Daniel, as the recipient here, with the current
i915 maintainers to get a faster feedback next time :)
<SNIP>
> This is now a conflict between the drm tree and Linus' tree.
>
My bad for not highlighting the merge conflict in my PR to Dave. He
probably did not notice, getting the resolution automatically from
drm-rerere, I'd guess. I've noted it in the ever improving draft of
things to remember with the PRs.
I'm very much currently flying based on what the previous PR authors
have remembered to tell me. But after 4.17, the cycle is complete and we
all "have been there, done that", and you can expect less of a turbulence.
(We'll probably have more magnificent documentation, too.)
Regards, Joonas
> --
> Cheers,
> Stephen Rothwell
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists•freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists•freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-11-14 19:29 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-11-13 23:23 linux-next: manual merge of the drm-intel tree with Linus' tree Stephen Rothwell
2022-11-14 8:19 ` Hans de Goede
2022-11-14 10:10 ` Jani Nikula
2022-11-14 10:35 ` Hans de Goede
2022-11-14 11:02 ` Jani Nikula
2022-11-14 19:29 ` [Intel-gfx] " Rodrigo Vivi
-- strict thread matches above, loose matches on Subject: below --
2018-03-22 2:21 Stephen Rothwell
2018-03-23 0:50 ` Stephen Rothwell
2018-03-23 14:16 ` [Intel-gfx] " Joonas Lahtinen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox