Re: linux-next: manual merge of the drm-intel tree with Linus' tree
Hi,
On 9/8/20 1:04 PM, Stephen Rothwell wrote:
Hi Hans,
On Tue, 8 Sep 2020 10:22:06 +0200 Hans de Goede wrote:
On 9/8/20 6:00 AM, Stephen Rothwell wrote:
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_panel.c
between commit:
f8bd54d21904 ("drm/i915: panel: Use atomic PWM API for devs with an external PWM
controller")
This should have been
899c537c25f9 ("drm/i915: Use 64-bit division macro")
Yes that makes more sense.
from Linus' tree and commit:
6b51e7d23aa8 ("drm/i915: panel: Honor the VBT PWM frequency for devs with an
external PWM controller")
That doesn't sound correct, those are both commits from the drm-intel tree.
from the drm-intel tree.
I fixed it up (I just used the latter)
Just taking the drivers/gpu/drm/i915/display/intel_panel.c contents of:
f8bd54d21904 ("drm/i915: panel: Use atomic PWM API for devs with an external PWM
controller")
Is the right thing to do, the problem is a difference in a line which gets
removed in that commit.
Which is what I actually did, I guess :-)
Yes, looks good.
Sorry about that.
No problem and thank you for all the work you do on -next.
Regards,
Hans
Re: linux-next: manual merge of the drm-intel tree with Linus' tree
Hi Hans,
On Tue, 8 Sep 2020 10:22:06 +0200 Hans de Goede wrote:
>
> On 9/8/20 6:00 AM, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm-intel tree got a conflict in:
> >
> >drivers/gpu/drm/i915/display/intel_panel.c
> >
> > between commit:
> >
> >f8bd54d21904 ("drm/i915: panel: Use atomic PWM API for devs with an
> > external PWM controller")
This should have been
899c537c25f9 ("drm/i915: Use 64-bit division macro")
> >
> > from Linus' tree and commit:
> >
> >6b51e7d23aa8 ("drm/i915: panel: Honor the VBT PWM frequency for devs
> > with an external PWM controller")
>
> That doesn't sound correct, those are both commits from the drm-intel tree.
>
> > from the drm-intel tree.
> >
> > I fixed it up (I just used the latter)
>
> Just taking the drivers/gpu/drm/i915/display/intel_panel.c contents of:
>
> f8bd54d21904 ("drm/i915: panel: Use atomic PWM API for devs with an external
> PWM controller")
>
> Is the right thing to do, the problem is a difference in a line which gets
> removed in that commit.
Which is what I actually did, I guess :-)
Sorry about that.
--
Cheers,
Stephen Rothwell
pgpCRSfVB_ZV8.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the drm-intel tree with Linus' tree
Hi Stephen,
On 9/8/20 6:00 AM, 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_panel.c
between commit:
f8bd54d21904 ("drm/i915: panel: Use atomic PWM API for devs with an external PWM
controller")
from Linus' tree and commit:
6b51e7d23aa8 ("drm/i915: panel: Honor the VBT PWM frequency for devs with an
external PWM controller")
That doesn't sound correct, those are both commits from the drm-intel tree.
from the drm-intel tree.
I fixed it up (I just used the latter)
Just taking the drivers/gpu/drm/i915/display/intel_panel.c contents of:
f8bd54d21904 ("drm/i915: panel: Use atomic PWM API for devs with an external PWM
controller")
Is the right thing to do, the problem is a difference in a line which gets
removed in that commit.
Regards,
Hans
Re: linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell
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..
> --- 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
pgpf5c_MGaLya.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the drm-intel tree with Linus' tree
Hi Daniel, On Tue, 7 May 2013 10:43:17 +0200 Daniel Vetter wrote: > > On Tue, May 7, 2013 at 3:27 AM, Stephen Rothwell > wrote: > > > > Daniel, I assume all this stuff being added to the drm-intel tree is > > going upstream very soon? > > Oops, no that is stuff for 3.11. Lazy me hoped I could sneak stuff > through (since we just keep on merging features to > drm-intel-next-queued to avoid stalls), but that's obviously not what > you want for linux-next. My apologies for that mess. I've now created > a for-linux-next branch which will not contain patches heading for > 3.x+1 while 3.x-rc1 hasn't been released yet. > > Can you please switch over to that branch for inclusion into linux-next? Done. Thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpfK7WZfCRdP.pgp Description: PGP signature
Re: linux-next: manual merge of the drm-intel tree with Linus' tree
On Tue, May 7, 2013 at 3:27 AM, Stephen Rothwell wrote:
> 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 a65851af5938 ("drm/i915:
> Make data/link N value power of two") from Linus' tree and commit
> e3b95f1eb5b9 ("drm/i915: Apply OCD to data/link m/n register #defines")
> from the drm-intel tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> Daniel, I assume all this stuff being added to the drm-intel tree is
> going upstream very soon?
Oops, no that is stuff for 3.11. Lazy me hoped I could sneak stuff
through (since we just keep on merging features to
drm-intel-next-queued to avoid stalls), but that's obviously not what
you want for linux-next. My apologies for that mess. I've now created
a for-linux-next branch which will not contain patches heading for
3.x+1 while 3.x-rc1 hasn't been released yet.
Can you please switch over to that branch for inclusion into linux-next?
Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the drm-intel tree with Linus' tree
On Wed, Apr 03, 2013 at 01:43:49PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in
> drivers/gpu/drm/i915/intel_panel.c between commit b1289371fcd5 ("Revert
> "drm/i915: write backlight harder"") from Linus' tree and commit
> 31ad8ec6a614 ("drm/i915: group backlight related stuff into a struct")
> from the drm-intel tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, I carry the same merge resolution locally.
-Daniel
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/gpu/drm/i915/intel_panel.c
> index bee8cb6,0e7e873..000
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@@ -318,9 -321,16 +321,13 @@@ void intel_panel_enable_backlight(struc
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> - if (dev_priv->backlight_level == 0)
> - dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
> + if (dev_priv->backlight.level == 0) {
> + dev_priv->backlight.level = intel_panel_get_max_backlight(dev);
> + if (dev_priv->backlight.device)
> + dev_priv->backlight.device->props.brightness =
> + dev_priv->backlight.level;
> + }
>
> -dev_priv->backlight.enabled = true;
> -intel_panel_actually_set_backlight(dev, dev_priv->backlight.level);
> -
> if (INTEL_INFO(dev)->gen >= 4) {
> uint32_t reg, tmp;
>
> @@@ -356,12 -366,12 +363,12 @@@
> }
>
> set_level:
> -/* Check the current backlight level and try to set again if it's zero.
> - * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically
> - * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written.
> +/* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1.
> + * BLC_PWM_CPU_CTL may be cleared to zero automatically when these
> + * registers are set.
>*/
> - dev_priv->backlight_enabled = true;
> - intel_panel_actually_set_backlight(dev, dev_priv->backlight_level);
> -if (!intel_panel_get_backlight(dev))
> -intel_panel_actually_set_backlight(dev,
> dev_priv->backlight.level);
> ++dev_priv->backlight.enabled = true;
> ++intel_panel_actually_set_backlight(dev, dev_priv->backlight.level);
> }
>
> static void intel_panel_init_backlight(struct drm_device *dev)
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
