public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox