From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Sujaritha <sujaritha.sundaresan@intel.com>,
Michal Wajdeczko <michal.wajdeczko@intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v8 2/6] drm/i915/guc : Removing i915_modparams.enable_guc_loading module parameter
Date: Fri, 03 Nov 2017 10:25:07 +0200 [thread overview]
Message-ID: <1509697507.4545.9.camel@linux.intel.com> (raw)
In-Reply-To: <7a5a331d-4063-b1bb-73bf-b74d2e8d3cd4@intel.com>
On Thu, 2017-11-02 at 09:34 -0700, Sujaritha wrote:
>
> On 10/25/2017 08:26 AM, Michal Wajdeczko wrote:
> > On Tue, 24 Oct 2017 19:21:21 +0200, Sujaritha Sundaresan
> > <sujaritha.sundaresan@intel.com> wrote:
> >
> > > We currently have two module parameters that control GuC:
> > > "enable_guc_loading" and "enable_guc_submission". Whenever
> > > we need submission=1, we also need loading=1.We also need
> > > loading=1 when we want to want to verify the HuC, which
> > > is every time we have a HuC (but all platforms with HuC
> > > have a GuC and viceversa).
> > >
> > > Also if we have HuC have firmware to be loaded, we need to
> > > have GuC to actually load it. So if the user wants to avoid
> > > the GuC from getting loaded, they must not have a HuC
> > > firmware to be loaded, in addition to not using submission.
> >
> > Hmm, I'm not sure that removal of HuC firmware file is the best
> > way for the user to stop undesired GuC loading.
> >
> > I know that we want to minimize number of modparams, but maybe
> > new i915.enable_huc=auto(-1)|never(0)|if available(1)|required(2)
> > will solve here ...
> >
> > Alternatively we can replace both existing modparams with single:
> >
> > i915.enable_guc = off(0) | auto(1) | submission(2) | huc(4)
> >
> > then we could cover almost all cases:
> >
> > 0 = GuC loading disabled (no GuC submission, no HuC)
> > 1 = GuC loading auto
> > 2 = GuC loading enabled, GuC submission required, HuC disabled
> > 3 = GuC loading enabled, GuC submission enabled, HuC disabled
> > 4 = GuC loading enabled, GuC submission disabled, HuC required
> > 5 = GuC loading enabled, GuC submission disabled, HuC enabled
> > 6 = GuC loading enabled, GuC submission required, HuC required
> > 7 = GuC loading enabled, GuC submission enabled, HuC enabled
Do we really need all these combinations.
My understanding is that we got three cases:
1. Load and use GuC, HuC goes on the side
2. Load GuC, just to get HuC
3. Don't load GuC at all
Which could be mapped to .enable_guc:
-1 = default (driver does as sees fit)
0 = no GuC, no nothing
1 = load and use GuC, HuC comes on the side
2 = Load GuC only, for HuC
Or if you want just the GuC without HuC at times, then
0x1 = Use GuC
0x2 = Use Huc
Loading is then implied. Somebody could remind me why we should
consider required, disabled vs. enabled options?
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-11-03 8:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 17:21 [PATCH v8 0/6] drm/i915/guc : Removing enable_guc_loading module and Decoupling logs and ADS from submission Sujaritha Sundaresan
2017-10-24 17:21 ` [PATCH v8 1/6] drm/i915 : Unifying seq_puts messages for feature support Sujaritha Sundaresan
2017-10-25 13:31 ` Michal Wajdeczko
2017-10-26 17:54 ` Daniele Ceraolo Spurio
2017-10-30 4:49 ` Sagar Arun Kamble
2017-10-31 18:24 ` Sujaritha
2017-10-31 18:28 ` Sujaritha
2017-10-31 18:27 ` Sujaritha
2017-10-24 17:21 ` [PATCH v8 2/6] drm/i915/guc : Removing i915_modparams.enable_guc_loading module parameter Sujaritha Sundaresan
2017-10-25 15:26 ` Michal Wajdeczko
2017-11-02 16:34 ` Sujaritha
2017-11-03 8:25 ` Joonas Lahtinen [this message]
2017-11-03 10:33 ` Jani Nikula
2017-11-03 13:38 ` Joonas Lahtinen
2017-10-24 17:21 ` [PATCH v8 3/6] drm/i915/guc : GEM_BUG_ON for GuC reset function Sujaritha Sundaresan
2017-10-24 17:21 ` [PATCH v8 4/6] drm/i915/guc : Updating GuC and HuC firmware select function Sujaritha Sundaresan
2017-10-25 15:56 ` Michal Wajdeczko
2017-11-02 18:21 ` Sujaritha
2017-10-24 17:21 ` [PATCH v8 5/6] drm/i915/guc : Updating GuC logs to remove enable_guc_submission parameter Sujaritha Sundaresan
2017-10-30 7:44 ` Sagar Arun Kamble
2017-10-24 17:21 ` [PATCH v8 6/6] drm/i915/guc : Decouple logs and ADS from submission Sujaritha Sundaresan
2017-10-25 16:19 ` Michal Wajdeczko
2017-11-02 9:23 ` Sagar Arun Kamble
2017-11-02 15:59 ` Sujaritha
2017-10-24 17:54 ` ✗ Fi.CI.BAT: warning for drm/i915/guc : Removing enable_guc_loading module and Decoupling logs and ADS from submission (rev3) Patchwork
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=1509697507.4545.9.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=michal.wajdeczko@intel.com \
--cc=sujaritha.sundaresan@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.