Re: [PATCH v8 2/6] drm/i915/guc : Removing i915_modparams.enable_guc_loading module parameter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux