More WOPCM fixes
Michal Wajdeczko (4):
drm/i915/wopcm: Check WOPCM layout separately from calculations
drm/i915/wopcm: Try to use already locked WOPCM layout
drm/i915/wopcm: Update error messages
drm/i915/wopmc: Fix SPDX tag location
Michał Winiarski (1):
drm/i915/uc: Move FW size
ned-off-by: Michał Winiarski
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 11 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 ++-
drive
(i.e. quirks). These are device specific messages, so
use the dev family of printk.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 6 --
drivers/gpu/drm/i915/i915_drv.c| 3 ++-
drivers/gpu/drm/i915
On Wed, 14 Aug 2019 22:10:51 +0200, Daniele Ceraolo Spurio
wrote:
On 8/14/19 12:51 PM, Daniele Ceraolo Spurio wrote:
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely differen
From: Michał Winiarski
While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime.
v2: rebased
Signed-off-by: Michał Winiarski
Signed-off-by: Michal
with slightly different
HuC firmware (or even without HuC) without need to reboot.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Michal Winiarski
---
drivers/gpu/drm/i915/intel_wopcm.c | 29 +++--
1 file changed, 27 insertions(+), 2 dele
Spurio
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 0dc2b0cf4604..c698cddc14dc 100644
--- a/drivers/gpu/drm/i915/gt/uc
We don't care about internal firmware status changes unless
we are doing some real debugging. Note that our CI is not
using DRM_I915_DEBUG_GUC config by default so use it.
v2: protect against accidental overwrites (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc:
We don't care about internal firmware status changes unless
we are doing some real debugging. Note that our CI is not
using DRM_I915_DEBUG_GUC config by default so use it.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc
On Mon, 12 Aug 2019 11:36:22 +0200, Chris Wilson
wrote:
However, you did alternate between /* SPDX */ and // SPDX with no rhyme
or reason I could see.
https://elixir.bootlin.com/linux/latest/source/Documentation/process/license-rules.rst
"The SPDX license identifier in kernel files shall b
Include 2019 in copyright years and start using SPDX tag.
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 23 ++
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 23 ++
drivers/gpu/drm/i915
On Mon, 12 Aug 2019 10:40:19 +0200, Patchwork
wrote:
== Series Details ==
Series: Use -EIO code for GuC initialization failures (rev2)
URL : https://patchwork.freedesktop.org/series/65060/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6681 -> Patchwork_13979
After successful uC initialization we are reporting GuC
firmware version and status of GuC submission and HuC.
Add HuC fw version to this report to make it complete,
but also skip all HuC info if HuC is not supported.
v2: squeeze to one line (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele
ven read related
GuC error log to investigate cause of the problem.
For now always return -EIO on any uC hardware related failure.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 11 +++
drivers/gpu/drm/i915/i
After successful uC initialization we are reporting GuC
firmware version and status of GuC submission and HuC.
Add HuC fw version to this report to make it complete,
but also skip all HuC info if HuC is not supported.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Our old messages were redundant or misleading (as loaded is
not the same as running). Keep only one message for debug.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 14 +++---
1 file changed, 3 insertions
We don't want to rely on misleading WOPCM partitioning error.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 5 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 21 +
2 files change
Next portion of GuC/HuC improvements
Michal Wajdeczko (4):
drm/i915/uc: Fail early if there is no GuC fw available
drm/i915/uc: Include HuC firmware version in summary
drm/i915/uc: Update messages from fw upload step
drm/i915/uc: Use -EIO code for GuC initialization failures
drivers/gpu
On Wed, 07 Aug 2019 22:21:29 +0200, Kumar Valsan, Prathap
wrote:
On Wed, Aug 07, 2019 at 05:00:29PM +, Michal Wajdeczko wrote:
There is no point in selecting HuC firmware if GuC is unsupported
or it was already disabled, as we need GuC to authenticate HuC.
We are calling
-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 142 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 3 +
2 files changed, 98 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc
Insert few more failure points into firmware fetch procedure to check
use of the wrong blob name or use of the mismatched firmware versions.
Also update some messages (remove ptr, duplicated infos) and stop
treating all fetch errors as missing firmware case.
Signed-off-by: Michal Wajdeczko
Cc
No need to define it globally as we're only using it in wopcm.c
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 5 -
drivers/gpu/drm/i915/intel_wopcm.c | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
For meaningful WOPCM partitioning we need GuC (and optionally HuC)
firmware size(s) and we shouldn't just rely on GuC support flag,
as we might fail to fetch GuC firmware and it's size will be 0
and all calculations will be just wrong/useless.
Signed-off-by: Michal Wajdeczko
Cc: Danie
There is no point in selecting HuC firmware if GuC is unsupported
or it was already disabled, as we need GuC to authenticate HuC.
While around, make uc_fw_init_early work without direct access
to whole i915, pass only needed platform/rev info.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo
WOPCM programming error might be due to inserted earlier probe
failure that could affects HuC firmware loading and thus impacts
result of WOPCM partitioning that would be now incompatible with
previously programmed values.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris
While modparams are global for the i915 module, we are reporting
status of the params applied against specific device instance.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 25 -
1 file changed
When we failed to fetch GuC firmware there is no point in fetching
HuC firmware as we will not be able to use it without working GuC.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 5 -
drivers/gpu/drm/i915/gt/uc
More probe failures inside uc loading path.
Michal Wajdeczko (7):
drm/i915/uc: Prefer dev_info for reporting options
drm/i915/uc: HuC firmware can't be supported without GuC
drm/i915/uc: Don't fetch HuC fw if GuC fw fetch already failed
drm/i915: Don't try to partition WO
On Mon, 05 Aug 2019 19:24:57 +0200, Chris Wilson
wrote:
So we just leave the HuC uninitialised and HUC_STATUS should then report
no authentication. (We do scrub that at some point just in case the
million resets did not?)
Bspec says that it's RO from the host and it will be 0 out of reset
_
On Sun, 04 Aug 2019 22:18:51 +0200, Patchwork
wrote:
== Series Details ==
Series: Don't fail on HuC early init errors
URL : https://patchwork.freedesktop.org/series/64668/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6624 -> Patchwork_13866
=
until hardware
initialization phase where we can decide about next steps.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 7 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8
2 files changed, 10 insertions(+), 5 del
Next step to ignore all HuC related errors
Michal Wajdeczko (4):
drm/i915/guc: Prefer intel_guc_is_submission_supported
drm/i915/huc: Prefer intel_huc_is_supported
drm/i915/uc: Remove redundant GuC support checks
drm/i915/uc: Don't fail on HuC early init errors
drivers/gpu/drm/i9
Since commit db81bc6eb9c0 ("drm/i915/uc: Consider enable_guc
modparam during fw selection") we have started using firmware
status as main indicator of the GuC support. No need to use
same checks twice.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
d
No need to dance with intel_uc_supports_huc(uc) as we
can directly use intel_huc_is_supported(huc)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
No need to use intel_uc_supports_guc_submission(uc) as we
can directly use intel_guc_is_submission_supported(guc)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 8
1 file changed, 4 insertions(+), 4 deletions
v3: fix Gen9 issue discovered by the v2
v4: rebased
v5: more injected errors and more fixes
v7: hot fixes moved to separate patches
Michal Wajdeczko (6):
drm/i915: Add i915 to i915_inject_probe_failure
drm/i915/uc: Do full sanitize instead of pure reset
drm/i915/uc: Reorder firmware status
Inject probe errors into intel_uc_init_hw to make sure we
correctly handle any uC initialization failure.
To avoid complains from CI about injected errors use
i915_probe_error to lower message level.
v4: rebased after moving hot fixes moved to separate patches
Signed-off-by: Michal Wajdeczko
ide the GT ones") we cleanup uc after gem.
Move captured GuC load error log to uc struct and release it
in intel_uc_fini() instead of intel_uc_driver_late_release()
Note that intel_uc_driver_late_release() is now empty, but
we can leave it as a placeholder for future code.
Signed-off-by: Micha
We don't have to immediately fail on WOPCM partitioning, we can wait
until we will start programming WOPCM registers. This should give us
more options if we decide to restore fallback in case of GuC failures.
v3: rebased
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc:
;3> [229.656740] intel_uc_fw_upload:425 GEM_BUG_ON(intel_uc_fw_is_loaded(uc_fw))
as we performed only pure reset and didn't sanitized HuC fw status.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +++---
1 file changed, 3 ins
-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/display/intel_connector.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 27 ++-
drivers/gpu
wrongly treated as
unavailable since its status code was not matching status check logic.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --gi
On Fri, 02 Aug 2019 20:07:22 +0200, Daniele Ceraolo Spurio
wrote:
On 8/2/19 10:02 AM, Michal Wajdeczko wrote:
On Fri, 02 Aug 2019 15:30:19 +0200, Chris Wilson
wrote:
Quoting Patchwork (2019-08-02 14:12:38)
== Series Details ==
Series: add more probe failures (rev6)
URL : https
On Fri, 02 Aug 2019 15:30:19 +0200, Chris Wilson
wrote:
Quoting Patchwork (2019-08-02 14:12:38)
== Series Details ==
Series: add more probe failures (rev6)
URL : https://patchwork.freedesktop.org/series/64390/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6614 -> Patchw
Use section name "Return" and proper error code -ETIMEDOUT
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_unco
v3: fix Gen9 issue discovered by the v2
v4: rebased
v5: more injected errors and more fixes
Michal Wajdeczko (3):
drm/i915: Add i915 to i915_inject_probe_failure
drm/i915/uc: Inject probe errors into intel_uc_init_hw
drm/i915/wopcm: Don't fail on WOPCM partitioning failure
.../gp
failed fw is still available
add more failure points
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Reviewed-by: Chris Wilson #v1
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 8 +---
drivers/gpu
-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/display/intel_connector.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 27 ++-
drivers/gpu
We don't have to immediately fail on WOPCM partitioning, we can wait
until we will start programming WOPCM registers. This should give us
more options if we decide to restore fallback in case of GuC failures.
v3: rebased
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc:
-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/display/intel_connector.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 27 ++-
drivers/gpu
v3: fix Gen9 issue discovered by the v2
v4: rebased
Michal Wajdeczko (3):
drm/i915: Add i915 to i915_inject_probe_failure
drm/i915/uc: Inject probe errors into intel_uc_init_hw
drm/i915/wopcm: Don't fail on WOPCM partitioning failure
.../gpu/drm/i915/display/intel_connector.c
We don't have to immediately fail on WOPCM partitioning, we can wait
until we will start programming WOPCM registers. This should give us
more options if we decide to restore fallback in case of GuC failures.
v3: rebased
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc:
Inject probe errors into intel_uc_init_hw to make sure we
correctly handle any uC initialization failure.
To avoid complains from CI about injected errors use
i915_probe_error to lower message level.
v2: _sanitize instead _reset to correctly handle Gen9 retries
Signed-off-by: Michal Wajdeczko
On Thu, 01 Aug 2019 17:27:22 +0200, Chris Wilson
wrote:
<7> [229.655762] [drm:intel_uc_fw_upload [i915]] HuC fw load
i915/kbl_huc_ver02_00_1810.bin
<7> [229.656489] [drm:intel_uc_fw_upload [i915]] HuC fw xfer completed
<6> [229.656490] [drm] HuC: Loaded firmware
i915/kbl_huc_ver02_00_181
-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/display/intel_connector.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 27 ++-
drivers/gpu
Inject probe errors into intel_uc_init_hw to make sure we
correctly handle any uC initialization failure.
To avoid complains from CI about injected errors use
i915_probe_error to lower message level.
v2: _sanitize instead _reset to correctly handle Gen9 retries
Signed-off-by: Michal Wajdeczko
v3: fix Gen9 issue discovered by the v2
Michal Wajdeczko (3):
drm/i915: Add i915 to i915_inject_probe_failure
drm/i915/uc: Inject probe errors into intel_uc_init_hw
drm/i915/wopcm: Don't fail on WOPCM partitioning failure
.../gpu/drm/i915/display/intel_connector.c| 2 +-
driver
We don't have to immediately fail on WOPCM partitioning, we can wait
until we will start programming WOPCM registers. This should give us
more options if we decide to restore fallback in case of GuC failures.
v2: rebased
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc:
As we already track GuC/HuC uses by other means than modparam
there is no point in sanitizing it. Just scan modparam for
major discrepancies between what was requested vs actual.
v2: rebased, reworded info messages
v3: oops
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris
On Thu, 01 Aug 2019 00:33:21 +0200, Michal Wajdeczko
wrote:
+ if (i915_modparams.enable_guc & ~(ENABLE_GUC_SUBMISSION ||
+ ENABLE_GUC_LOAD_HUC))
oops, again
___
Intel-gfx mailing list
Intel
gister(&pmu->base);
err:
- i915->pmu.base.event_init = NULL;
- free_event_attributes(i915);
+ pmu->base.event_init = NULL;
+ free_event_attributes(pmu);
DRM_NOTE("Failed to register PMU! (err=%d)\n", ret);
}
void i91
Rename intel_uc_is_using* into intel_uc_supports* to make clear
distinction from actual state (compare intel_uc_fw_is_running)
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 8 ++---
drivers
As we already track GuC/HuC uses by other means than modparam
there is no point in sanitizing it. Just scan modparam for
major discrepancies between what was requested vs actual.
v2: rebased, reworded info messages
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
We can use value of enable_guc modparam during firmware path selection
and start using firmware status to see if GuC/HuC is being used.
This is first step to make enable_guc modparam read-only.
v2: rebased, don't care about <0 (Chris)
v3: oops
Signed-off-by: Michal Wajdeczko
Cc: Daniele
v3: oops
Michal Wajdeczko (4):
drm/i915/uc: Rename intel_uc_is_using* into intel_uc_supports*
drm/i915/uc: Consider enable_guc modparam during fw selection
drm/i915/guc: Use dedicated flag to track submission mode
drm/i915/uc: Stop sanitizing enable_guc modparam
drivers/gpu/drm/i915/gt
Instead of relying on enable_guc modparam to represent actual
GuC submission mode, use dedicated flag and look at modparam
only to check if submission was explicitly disabled by the user.
v2: rebased, simplified condition (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc
On Wed, 31 Jul 2019 22:49:57 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-07-31 15:38:53)
@@ -365,12 +365,12 @@ void intel_uc_fini(struct intel_uc *uc)
{
struct intel_guc *guc = &uc->guc;
- if (!intel_uc_is_using_guc(uc))
+ if (!intel_uc_supports
We can use value of enable_guc modparam during firmware path selection
and start using firmware status to see if GuC/HuC is being used.
This is first step to make enable_guc modparam read-only.
v2: rebased, don't care about <0 (Chris)
v3: oops
Signed-off-by: Michal Wajdeczko
Cc: Daniele
On Wed, 31 Jul 2019 19:47:27 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-07-31 15:38:54)
+static const char *__override_guc_firmware_path(void)
+{
+ if (i915_modparams.enable_guc & (ENABLE_GUC_SUBMISSION ||
+ENABLE_GUC_LOAD
-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
.../gpu/drm/i915/display/intel_connector.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 27 ++-
drivers/gpu/drm/i915/i915_drv.h
Inject probe errors into intel_uc_init_hw to make sure we
correctly handle any uC initialization failure.
To avoid complains from CI about injected errors use
i915_probe_error to lower message level.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu
We don't have to immediately fail on WOPCM partitioning, we can wait
until we will start programming WOPCM registers. This should give us
more options if we decide to restore fallback in case of GuC failures.
v2: rebased
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc:
v2: rebased
Michal Wajdeczko (3):
drm/i915: Add i915 to i915_inject_probe_failure
drm/i915/uc: Inject probe errors into intel_uc_init_hw
drm/i915/wopcm: Don't fail on WOPCM partitioning failure
.../gpu/drm/i915/display/intel_connector.c| 2 +-
drivers/gpu/drm/i9
We can use value of enable_guc modparam during firmware path selection
and start using firmware status to see if GuC/HuC is being used.
This is first step to make enable_guc modparam read-only.
v2: rebased, don't care about <0 (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraol
v2: rename + don't care about undocumented values <0
changes in IGT to stop using enable_guc modparam to detect
guc_submission mode will follow shortly
Michal Wajdeczko (4):
drm/i915/uc: Rename intel_uc_is_using* into intel_uc_supports*
drm/i915/uc: Consider enable_guc modparam d
As we already track GuC/HuC uses by other means than modparam
there is no point in sanitizing it. Just scan modparam for
major discrepancies between what was requested vs actual.
v2: rebased, reworded info messages
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Rename intel_uc_is_using* into intel_uc_supports* to make clear
distinction from actual state (compare intel_uc_fw_is_running)
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 8 ++---
drivers/gpu/drm/i915/gt/uc
Instead of relying on enable_guc modparam to represent actual
GuC submission mode, use dedicated flag and look at modparam
only to check if submission was explicitly disabled by the user.
v2: rebased, simplified condition (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc
On Tue, 30 Jul 2019 21:07:28 +0200, Chris Wilson
wrote:
+static const char* __override_huc_firmware_path(void)
+{
+ if ((i915_modparams.enable_guc < 0) ||
+ (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC))
+ return i915_modparams.huc_firmware_path;
We can eve
-specific (although that is our main use-case), so
keep that separate.
v2: move write_and_verify to uncore, fix log, re-use err_out tag,
add intel_wopcm_guc_base, fix log
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Chris Wilson
---
--- a/drivers/gpu/drm/i915
split uc_resume and uc_runtime_resume to match the suspend
functions and to better differentiate the expected state in the 2
scenarios (Chris)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Chris Wilson
Reviewed-by: Michal Wajd
As we already track GuC/HuC uses by other means than modparam
there is no point in sanitizing it. Just scan modparam for
major discrepancies between what was requested vs actual.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc
We want to stop relying on modparam for runtime uC status
Michal Wajdeczko (3):
drm/i915/uc: Consider enable_guc modparam during fw selection
drm/i915/guc: Use dedicated flag to track submission mode
drm/i915/uc: Stop sanitizing enable_guc modparam
drivers/gpu/drm/i915/gt/uc/intel_guc.c
Instead of relying on enable_guc modparam to represent actual
GuC submission mode, use dedicated flag and look at modparam
only to check if submission was explicitly disabled by the user.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt
We can use value of enable_guc modparam during firmware path selection
and start using firmware status to see if GuC/HuC is being used.
This is first step to make enable_guc modparam read-only.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm
tency.
nit: s/uc/uC
nit: s/wopcm/WOPCM
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Michal Wajdeczko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedeskto
other side is not uC-specific (although that is our main use-case), so
keep that separate.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 62
drivers/gpu/drm/i915/i915_gem.c | 8 +---
drivers
f-contained, so can't add that.
References:
http://marc.info/?i=80bf2204-558a-6d3f-c493-bf17b891f...@infradead.org
Cc: Chris Wilson
Cc: Lionel Landwerlin
Cc: Michal Wajdeczko
Signed-off-by: Jani Nikula
Reviewed-by: Michal Wajdeczko
___
In
On Tue, 30 Jul 2019 09:06:19 +0200, Joonas Lahtinen
wrote:
Quoting Michal Wajdeczko (2019-07-29 14:26:12)
HuC is usually not a critical component, so we can safely ignore
firmware load or authentication failures unless HuC was explicitly
requested by the user.
Do we have the fault
On Tue, 30 Jul 2019 11:27:51 +0200, Chris Wilson
wrote:
Quoting Chris Wilson (2019-07-30 09:47:37)
Quoting Michal Wajdeczko (2019-07-29 16:23:00)
> Inject load errors into intel_uc_init_hw to make sure we
> correctly handle uC initialization failures.
>
> To avoid complains f
gned-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index bd9211b3d76e..332949c20a29 100644
--- a/drivers/gpu/drm/i915
We shouldn't immediately fail on WOPCM partitioning or programming
as we plan to restore fallback on any GuC related failures.
While around, add some more probe failure injections.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/
Inject load errors into intel_uc_init_hw to make sure we
correctly handle uC initialization failures.
To avoid complains from CI about inserted errors or warnings,
use helper macro that checks if there was an error injection.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris
On Mon, 29 Jul 2019 13:04:49 +0200, Chris Wilson
wrote:
As we store a pointer to i915 in the drvdata field (as the pointer is
both
an alias to the drm_device and drm_i915_private), we can use the stored
pointer directly as the i915 device.
as we store drm_device* there, let's always trea
There are still many places where we can inject failures,
but doing so without preparation may make CI unhappy as
it will treat any new ERROR/WARN very seriously.
Mitigate that by converting some of dmesg messages to
debug after injecting fake error.
Michal Wajdeczko (4):
drm/i915: Report
-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
.../gpu/drm/i915/display/intel_connector.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 27 ++-
drivers/gpu/drm/i915/i915_drv.h
On Mon, 29 Jul 2019 16:56:37 +0200, Patchwork
wrote:
== Series Details ==
Series: drm/i915/uc: Don't fail on HuC firmware failure (rev2)
URL : https://patchwork.freedesktop.org/series/64326/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6573 -> Patchwork_13785
==
HuC is usually not a critical component, so we can safely ignore
firmware load or authentication failures unless HuC was explicitly
requested by the user.
v2: add convenient way to disable loading (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Joonas
x27;dev_priv' description in 'intel_uc_fw_fetch'
Fixes: 97dee74bb34a ("drm/i915/uc: Reorder params in intel_uc_fw_fetch")
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
oops,
Reviewed-by: Michal Wajdeczko
__
On Fri, 26 Jul 2019 20:57:12 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-07-26 18:12:40)
HuC is usually not a critical component, so we can safely ignore
firmware load or authentication failures unless HuC was explicitly
requested by the user.
Signed-off-by: Michal Wajdeczko
401 - 500 of 1923 matches
Mail list logo
