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

[Joonas Lahtinen]

On Fri, 2017-11-03 at 12:33 +0200, Jani Nikula wrote:
> On Fri, 03 Nov 2017, Joonas Lahtinen  wrote:
> > 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 
> > > >  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.
> 
> Ugh, I hope not. Pick the combinations you're committed to testing. If
> it's not tested, it doesn't exist.
> 
> Side note, you also have guc_firmware_path and huc_firmware_path
> options.

Yep, I think I suggested them originally.

Then you only would have .enable_guc boolean for whether you want to
use GuC submission.

So I'm kinda looking forward to seeing a definitive list of what we
actually require by use-case and what we're committed to testing.

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

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

[Jani Nikula]

On Fri, 03 Nov 2017, Joonas Lahtinen  wrote:
> 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 
>> >  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.

Ugh, I hope not. Pick the combinations you're committed to testing. If
it's not tested, it doesn't exist.

Side note, you also have guc_firmware_path and huc_firmware_path
options.

BR,
Jani.

> 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

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

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

[Joonas Lahtinen]

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 
> >  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

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

[Sujaritha]

On 10/25/2017 08:26 AM, Michal Wajdeczko wrote:
On Tue, 24 Oct 2017 19:21:21 +0200, Sujaritha Sundaresan 
 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


This is a really good idea. I will include the new modparams in the next 
revision.





v2: Clarifying the commit message (Anusha)

v3: Unify seq_puts messages, Re-factoring code as per review (Michal)

v4: Rebase

v5: Separating message unification into a separate patch

v6: Re-factoring code (Sagar, Michal)
    Rebase

v7: Applying review comments (Sagar)
    Rebase

v8: Change to NEEDS_GUC_FW (Chris)
    Applying review comments (Michal)
    Clarifying commit message (Joonas)

Suggested by: Oscar Mateo 
Signed-off-by: Sujaritha Sundaresan 
Cc: Anusha Srivatsa 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  9 +++--
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
 drivers/gpu/drm/i915/i915_irq.c |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  4 ---
 drivers/gpu/drm/i915/i915_params.h  |  1 -
 drivers/gpu/drm/i915/intel_uc.c | 57 
+++--

 8 files changed, 34 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c

index 8edd029..25c47a0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2465,7 +2465,7 @@ static bool check_guc_submission(struct 
seq_file *m)

if (!guc->execbuf_client) {
 seq_printf(m, "GuC submission %s\n",
-   HAS_GUC_SCHED(dev_priv) ?
+   HAS_GUC(dev_priv) ?
    "disabled" :
    "not supported");


As I already said before, there is also 3rd possible status "failed"

!HAS_GUC(dev_priv) ? "not supported" :
    !HAS_GUC_SCHED(dev_priv) ? "disabled" :
    "failed"

where HAS_GUC_SCHED is

#define HAS_GUC_SCHED(dev_priv) \
    (HAS_GUC(dev_priv) && i915_modparams.enable_guc_submission)

or something similar



Sorry, I missed the third case. I will include it and the change to the 
macro condition

in the next revision.

 return false;
diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index f01c800..ede5004 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3205,9 +3205,11 @@ static inline unsigned int 
i915_sg_segment_size(void)

  */
 #define HAS_GUC(dev_priv)    ((dev_priv)->info.has_guc)
 #define HAS_GUC_CT(dev_priv) ((dev_priv)->info.has_guc_ct)
-#define HAS_GUC_UCODE(dev_priv)    (HAS_GUC(dev_priv))
-#define HAS_GUC_SCHED(dev_priv)    (HAS_GUC(dev_priv))
-#define HAS_HUC_UCODE(dev_priv)    (HAS_GUC(dev_priv))
+#define HAS_GUC_UCODE(dev_priv) ((dev_priv)->guc.fw.path != NULL)
+#define HAS_HUC_UCODE(dev_priv) ((dev_priv)->huc.fw.path != NULL)
+
+#define NEEDS_GUC_FW(dev_priv) \


Hmm, based on its usage, this name is now little confusing.
Maybe USES_GUC ? See USES_PPGTT|USES_FULL_PPGTT|USES_FULL_48BIT_PPGTT


I would really prefer to keep NEEDS_GUC_FW


+    (HAS_GUC(dev_priv) && \
+    (i915_modparams.enable_guc_submission || 
HAS_HUC_UCODE(dev_priv)))


While unlikely, above will be true even with 

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

[Michal Wajdeczko]

On Tue, 24 Oct 2017 19:21:21 +0200, Sujaritha Sundaresan  
 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




v2: Clarifying the commit message (Anusha)

v3: Unify seq_puts messages, Re-factoring code as per review (Michal)

v4: Rebase

v5: Separating message unification into a separate patch

v6: Re-factoring code (Sagar, Michal)
Rebase

v7: Applying review comments (Sagar)
Rebase

v8: Change to NEEDS_GUC_FW (Chris)
Applying review comments (Michal)
Clarifying commit message (Joonas)

Suggested by: Oscar Mateo 
Signed-off-by: Sujaritha Sundaresan 
Cc: Anusha Srivatsa 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  9 +++--
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
 drivers/gpu/drm/i915/i915_irq.c |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  4 ---
 drivers/gpu/drm/i915/i915_params.h  |  1 -
 drivers/gpu/drm/i915/intel_uc.c | 57  
+++--

 8 files changed, 34 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c  
b/drivers/gpu/drm/i915/i915_debugfs.c

index 8edd029..25c47a0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2465,7 +2465,7 @@ static bool check_guc_submission(struct seq_file  
*m)

if (!guc->execbuf_client) {
seq_printf(m, "GuC submission %s\n",
-  HAS_GUC_SCHED(dev_priv) ?
+  HAS_GUC(dev_priv) ?
   "disabled" :
   "not supported");


As I already said before, there is also 3rd possible status "failed"

!HAS_GUC(dev_priv) ? "not supported" :
!HAS_GUC_SCHED(dev_priv) ? "disabled" :
"failed"

where HAS_GUC_SCHED is

#define HAS_GUC_SCHED(dev_priv) \
(HAS_GUC(dev_priv) && i915_modparams.enable_guc_submission)

or something similar


return false;
diff --git a/drivers/gpu/drm/i915/i915_drv.h  
b/drivers/gpu/drm/i915/i915_drv.h

index f01c800..ede5004 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3205,9 +3205,11 @@ static inline unsigned int  
i915_sg_segment_size(void)

  */
 #define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
 #define HAS_GUC_CT(dev_priv)   ((dev_priv)->info.has_guc_ct)
-#define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
+#define HAS_GUC_UCODE(dev_priv) ((dev_priv)->guc.fw.path != NULL)
+#define HAS_HUC_UCODE(dev_priv) ((dev_priv)->huc.fw.path != NULL)
+
+#define NEEDS_GUC_FW(dev_priv) \


Hmm, based on its usage, this name is now little confusing.
Maybe USES_GUC ? See USES_PPGTT|USES_FULL_PPGTT|USES_FULL_48BIT_PPGTT


+   (HAS_GUC(dev_priv) && \
+   (i915_modparams.enable_guc_submission || 
HAS_HUC_UCODE(dev_priv)))


While unlikely, above will be true even with guc.fw.path == NULL

Also, based on your statement "all platforms with HuC have a GuC
and viceversa" I would assume that corresponding firmwares will
be delivered also in 

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

[Sujaritha Sundaresan]

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.

v2: Clarifying the commit message (Anusha)

v3: Unify seq_puts messages, Re-factoring code as per review (Michal)

v4: Rebase

v5: Separating message unification into a separate patch

v6: Re-factoring code (Sagar, Michal)
Rebase

v7: Applying review comments (Sagar)
Rebase

v8: Change to NEEDS_GUC_FW (Chris)
Applying review comments (Michal)
Clarifying commit message (Joonas)

Suggested by: Oscar Mateo 
Signed-off-by: Sujaritha Sundaresan 
Cc: Anusha Srivatsa 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  9 +++--
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  2 +-
 drivers/gpu/drm/i915/i915_irq.c |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  4 ---
 drivers/gpu/drm/i915/i915_params.h  |  1 -
 drivers/gpu/drm/i915/intel_uc.c | 57 +++--
 8 files changed, 34 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8edd029..25c47a0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2465,7 +2465,7 @@ static bool check_guc_submission(struct seq_file *m)
 
if (!guc->execbuf_client) {
seq_printf(m, "GuC submission %s\n",
-  HAS_GUC_SCHED(dev_priv) ?
+  HAS_GUC(dev_priv) ?
   "disabled" :
   "not supported");
return false;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f01c800..ede5004 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3205,9 +3205,11 @@ static inline unsigned int i915_sg_segment_size(void)
  */
 #define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
 #define HAS_GUC_CT(dev_priv)   ((dev_priv)->info.has_guc_ct)
-#define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
-#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
+#define HAS_GUC_UCODE(dev_priv) ((dev_priv)->guc.fw.path != NULL)
+#define HAS_HUC_UCODE(dev_priv) ((dev_priv)->huc.fw.path != NULL)
+
+#define NEEDS_GUC_FW(dev_priv) \
+   (HAS_GUC(dev_priv) && \
+   (i915_modparams.enable_guc_submission || 
HAS_HUC_UCODE(dev_priv)))
 
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5bf96a2..4f0692e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -314,7 +314,7 @@ static u32 default_desc_template(const struct 
drm_i915_private *i915,
 * present or not in use we still need a small bias as ring wraparound
 * at offset 0 sometimes hangs. No idea why.
 */
-   if (HAS_GUC(dev_priv) && i915_modparams.enable_guc_loading)
+   if (NEEDS_GUC_FW(dev_priv))
ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
else
ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 527a2d2..9d78233 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3481,7 +3481,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private *dev_priv)
 * currently don't have any bits spare to pass in this upper
 * restriction!
 */
-   if (HAS_GUC(dev_priv) && i915_modparams.enable_guc_loading) {
+   if (NEEDS_GUC_FW(dev_priv)) {
ggtt->base.total = min_t(u64, ggtt->base.total, GUC_GGTT_TOP);
ggtt->mappable_end = min(ggtt->mappable_end, ggtt->base.total);
}
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1296a5..ec76aac 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4026,7 +4026,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
for (i = 0; i