[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <163655218578.6332.7934375733343731100@jlahtine-mobl.ger.corp.intel.com>
Date: Wed, 10 Nov 2021 15:49:45 +0200
From: Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>
To: Christoph Hellwig <hch@....de>
Cc: Christoph Hellwig <hch@....de>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Zhenyu Wang <zhenyuw@...ux.intel.com>,
Zhi Wang <zhi.a.wang@...el.com>,
Jason Gunthorpe <jgg@...dia.com>,
intel-gfx@...ts.freedesktop.org,
intel-gvt-dev@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: refactor the i915 GVT support and move to the modern mdev API v2
Quoting Christoph Hellwig (2021-11-09 09:59:57)
> On Thu, Nov 04, 2021 at 02:59:18PM +0200, Joonas Lahtinen wrote:
> > The minimal we should do is to eliminate the double underscore
> > prefixed functions. But I would prefer to have the symbol exports by
> > default so that we can enable the functionality just by loading the
> > module.
>
> I'm fine with exporting by default, but just loading won't really work
> even with that:
>
> - there are a bunch of IS_ENABLED conditionals in the i915 (although
> they look like minor optimizations to me).
I'd assume the golden state capture being the one with biggest impact.
> - the enable_gvt needs to be set, although after this refactor this
> option is completely pointless and should probably be enabled
Indeed. Hope is that modprobe/rmmod would be enough to enable/disable.
This should help any distros intending to enable the feature, too.
So mostly about making sure the IS_ENABLED portions in base i915
operation are not too invasive.
> - the enable_guc option needs to be disable for gvt to work.
On the GVT supported platforms GuC is disabled by default, so it should
be fine. We can change the logic to opposite to disable the feature if
the enable_guc unsafe modparam is used.
Regards, Joonas
Powered by blists - more mailing lists