All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
	"Yuan, Hang" <hang.yuan@intel.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	intel-gvt-dev <intel-gvt-dev@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PULL] gvt-gt-next
Date: Thu, 21 Jan 2021 16:17:50 +0200	[thread overview]
Message-ID: <87eeiel6gh.fsf@intel.com> (raw)
In-Reply-To: <161123722267.35611.5545479615611490821@jlahtine-mobl.ger.corp.intel.com>

On Thu, 21 Jan 2021, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> Quoting Joonas Lahtinen (2021-01-21 15:15:19)
>> Quoting Zhenyu Wang (2021-01-21 06:08:25)
>> > On 2021.01.20 14:21:53 +0200, Joonas Lahtinen wrote:
>> > > Quoting Zhenyu Wang (2021-01-18 07:07:39)
>> > > > 
>> > > > Hi,
>> > > > 
>> > > > This is GVT next for 5.12 against drm-intel-gt-next which is mostly
>> > > > for cmd parser enhancement which adds extra check on register load
>> > > > depending on initial context and handles vGPU register state
>> > > > accordingly.
>> > > 
>> > > I think we were bit inconclusive on this last time.
>> > >
>> > 
>> > Sorry about that, I was thinking we might just follow your previous idea.
>> > 
>> > > Even if this does not have any dependency to drm-intel-gt-next I can
>> > > pull this to drm-intel-gt-next. The only caveat is that for any -fixes,
>> > > there needs to be a backmerge to drm-intel-next.
>> > > 
>> > > Not sure if this is a problem. Do we want to make it a recurring practice
>> > > to backmerge drm-intel-gt-next into drm-intel-next after it lands in
>> > > drm-next?
>> > >
>> > 
>> > So -gt-next won't do -gt-next-fixes, right? For -next-fixes, we always do
>> > drm-next backmerge, right?
>> > 
>> > > So to recap: Do we want to pull to drm-intel-next whenever there are no
>> > > dependencies to drm-intel-gt-next, to avoid a backmerge?
>> > 
>> > yeah, that's fine to me. But for this time gvt-next pull, it's really targeting
>> > for -gt-next which has some dependency, I can double check to confirm.
>> 
>> I've now pulled to drm-intel-gt-next.
>
> There was a header test build failure noticed by Chris:
>
> drivers/gpu/drm/i915/gvt/cmd_parser.h:53:44: error: ‘struct intel_vgpu’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
>    53 | void intel_gvt_update_reg_whitelist(struct intel_vgpu *vgpu);

Please use CONFIG_DRM_I915_WERROR=y during development.

BR,
Jani.


>
> It's now fixed in drm-intel-gt-next, you may want to backmerge after
> drm-next lands the drm-intel-gt-next PR.
>
> Regards, Joonas
>
>> 
>> Indeed any changes in i915/gt side that affect GVT would become
>> dependencies.
>> 
>> I think it would be good to continue on the plan to build GVT as a
>> completely separate module and have a clear definition of the interface
>> between the two.
>> 
>> Regards, Joonas
>> 
>> > Thanks.
>> > 
>> > > Or do we want
>> > > to always do a backmerge in anticipation of -fixes.
>> > > 
>> > > Regards, Joonas
>> > > 
>> > > > Thanks.
>> > > > --
>> > > > The following changes since commit fe7bcfaeb2b775f257348dc7b935f8e80eef3e7d:
>> > > > 
>> > > >   drm/i915/gt: Refactor heartbeat request construction and submission (2020-12-24 18:07:26 +0000)
>> > > > 
>> > > > are available in the Git repository at:
>> > > > 
>> > > >   https://github.com/intel/gvt-linux tags/gvt-gt-next-2021-01-18
>> > > > 
>> > > > for you to fetch changes up to 02dd2b12a685944c4d52c569d05f636372a7b6c7:
>> > > > 
>> > > >   drm/i915/gvt: unify lri cmd handler and mmio handlers (2020-12-25 11:16:32 +0800)
>> > > > 
>> > > > ----------------------------------------------------------------
>> > > > gvt-gt-next-2021-01-18
>> > > > 
>> > > > - GVT cmd parser enhancement against guest context (Yan)
>> > > > 
>> > > > ----------------------------------------------------------------
>> > > > Yan Zhao (11):
>> > > >       drm/i915/gvt: parse init context to update cmd accessible reg whitelist
>> > > >       drm/i915/gvt: scan VM ctx pages
>> > > >       drm/i915/gvt: filter cmds "srm" and "lrm" in cmd_handler
>> > > >       drm/i915/gvt: filter cmds "lrr-src" and "lrr-dst" in cmd_handler
>> > > >       drm/i915/gvt: filter cmd "pipe-ctrl" in cmd_handler
>> > > >       drm/i915/gvt: export find_mmio_info
>> > > >       drm/i915/gvt: make width of mmio_attribute bigger
>> > > >       drm/i915/gvt: introduce a new flag F_CMD_WRITE_PATCH
>> > > >       drm/i915/gvt: statically set F_CMD_WRITE_PATCH flag
>> > > >       drm/i915/gvt: update F_CMD_WRITE_PATCH flag when parsing init ctx
>> > > >       drm/i915/gvt: unify lri cmd handler and mmio handlers
>> > > > 
>> > > >  drivers/gpu/drm/i915/gvt/cmd_parser.c | 335 +++++++++++++++++++++++++++-------
>> > > >  drivers/gpu/drm/i915/gvt/cmd_parser.h |   4 +
>> > > >  drivers/gpu/drm/i915/gvt/gvt.h        |  37 +++-
>> > > >  drivers/gpu/drm/i915/gvt/handlers.c   |  15 +-
>> > > >  drivers/gpu/drm/i915/gvt/mmio.h       |   3 +
>> > > >  drivers/gpu/drm/i915/gvt/reg.h        |   2 +
>> > > >  drivers/gpu/drm/i915/gvt/scheduler.c  |  22 ++-
>> > > >  drivers/gpu/drm/i915/gvt/vgpu.c       |   4 +-
>> > > >  8 files changed, 339 insertions(+), 83 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-01-21 14:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18  5:07 [Intel-gfx] [PULL] gvt-gt-next Zhenyu Wang
2021-01-20 12:21 ` Joonas Lahtinen
2021-01-20 15:55   ` Vivi, Rodrigo
2021-01-21  4:08   ` Zhenyu Wang
2021-01-21 13:15     ` Joonas Lahtinen
2021-01-21 13:53       ` Joonas Lahtinen
2021-01-21 14:17         ` Jani Nikula [this message]
2021-02-05  7:30 Zhenyu Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eeiel6gh.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=hang.yuan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhiyuan.lv@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.