aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/event_analyzing_sample.py
diff options
context:
space:
mode:
authorDaniele Ceraolo Spurio <[email protected]>2020-03-26 11:11:18 -0700
committerChris Wilson <[email protected]>2020-03-26 21:22:01 +0000
commit801a0caa627b3b2aa5933b66f0e4a83c4f85143e (patch)
tree3f741fde53cc755b1149835a2bca606b8d335666 /tools/perf/scripts/python/event_analyzing_sample.py
parent708249a6eba1e1b9c1abfdb400a19f1eb8aaf4d7 (diff)
drm/i915/huc: make "support huc" reflect HW capabilities
We currently initialize HuC support based on GuC being enabled in modparam; this means that huc_is_supported() can return false on HW that does have a HuC when enable_guc=0. The rationale for this behavior is that HuC requires GuC for authentication and therefore is not supported by itself. However, we do not allow defining HuC fw wthout GuC fw and selecting HuC in modparam implicitly selects GuC as well, so we can't actually hit a scenario where HuC is selected alone. Therefore, we can flip the support check to reflect the HW capabilities and fw availability, which is more intuitive and will make it cleaner to log HuC the difference between not supported in HW and not selected. Removing the difference between GuC and HuC also allows us to simplify the init_early, since we don't need to differentiate the support based on the type of uC. Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: John Harrison <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: John Harrison <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Diffstat (limited to 'tools/perf/scripts/python/event_analyzing_sample.py')
0 files changed, 0 insertions, 0 deletions