* [PATCH] drm/i915/huc: Check HuC status in dedicated function
@ 2018-03-14 20:04 Michal Wajdeczko
2018-03-14 20:17 ` Michel Thierry
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Michal Wajdeczko @ 2018-03-14 20:04 UTC (permalink / raw)
To: intel-gfx; +Cc: Rodrigo Vivi
We try to keep all HuC related code in dedicated file.
There is no need to peek HuC register directly during
handling getparam ioctl.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
drivers/gpu/drm/i915/intel_huc.c | 25 +++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_huc.h | 1 +
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f03555e..a902e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device *dev, void *data,
value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
- intel_runtime_pm_get(dev_priv);
- value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
- intel_runtime_pm_put(dev_priv);
+ value = intel_huc_check_status(&dev_priv->huc);
+ if (value < 0)
+ return value;
break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 1d6c47b..2912852 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
DRM_ERROR("HuC: Authentication failed %d\n", ret);
return ret;
}
+
+/**
+ * intel_huc_check_status() - check HuC status
+ * @huc: intel_huc structure
+ *
+ * This function reads status register to verify if HuC
+ * firmware was successfully loaded.
+ *
+ * Returns positive value if HuC firmware is loaded and verified
+ * and -ENODEV if HuC is not present.
+ */
+int intel_huc_check_status(struct intel_huc *huc)
+{
+ struct drm_i915_private *dev_priv = huc_to_i915(huc);
+ u32 status;
+
+ if (!HAS_HUC(dev_priv))
+ return -ENODEV;
+
+ intel_runtime_pm_get(dev_priv);
+ status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
+ intel_runtime_pm_put(dev_priv);
+
+ return status;
+}
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index b185850..aa85490 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -37,6 +37,7 @@ struct intel_huc {
void intel_huc_init_early(struct intel_huc *huc);
int intel_huc_auth(struct intel_huc *huc);
+int intel_huc_check_status(struct intel_huc *huc);
static inline int intel_huc_sanitize(struct intel_huc *huc)
{
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915/huc: Check HuC status in dedicated function
2018-03-14 20:04 [PATCH] drm/i915/huc: Check HuC status in dedicated function Michal Wajdeczko
@ 2018-03-14 20:17 ` Michel Thierry
2018-03-14 22:23 ` Michal Wajdeczko
2018-03-14 20:58 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-03-15 1:31 ` ✗ Fi.CI.IGT: failure " Patchwork
2 siblings, 1 reply; 7+ messages in thread
From: Michel Thierry @ 2018-03-14 20:17 UTC (permalink / raw)
To: Michal Wajdeczko, intel-gfx; +Cc: Rodrigo Vivi
On 14/03/18 13:04, Michal Wajdeczko wrote:
> We try to keep all HuC related code in dedicated file.
> There is no need to peek HuC register directly during
> handling getparam ioctl.
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Michel Thierry <michel.thierry@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
> drivers/gpu/drm/i915/intel_huc.c | 25 +++++++++++++++++++++++++
> drivers/gpu/drm/i915/intel_huc.h | 1 +
> 3 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f03555e..a902e88 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device *dev, void *data,
> value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
> break;
> case I915_PARAM_HUC_STATUS:
> - intel_runtime_pm_get(dev_priv);
> - value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> - intel_runtime_pm_put(dev_priv);
> + value = intel_huc_check_status(&dev_priv->huc);
> + if (value < 0)
> + return value;
> break;
> case I915_PARAM_MMAP_GTT_VERSION:
> /* Though we've started our numbering from 1, and so class all
> diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
> index 1d6c47b..2912852 100644
> --- a/drivers/gpu/drm/i915/intel_huc.c
> +++ b/drivers/gpu/drm/i915/intel_huc.c
> @@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
> DRM_ERROR("HuC: Authentication failed %d\n", ret);
> return ret;
> }
> +
> +/**
> + * intel_huc_check_status() - check HuC status
> + * @huc: intel_huc structure
> + *
> + * This function reads status register to verify if HuC
> + * firmware was successfully loaded.
> + *
> + * Returns positive value if HuC firmware is loaded and verified
> + * and -ENODEV if HuC is not present.
Before if huc was not loaded, get_param would just return 0 and the
ioctl call would be OK. Maybe there's a test somewhere that would break?
(I'm not arguing -ENODEV is better).
Otherwise,
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
> + */
> +int intel_huc_check_status(struct intel_huc *huc)
> +{
> + struct drm_i915_private *dev_priv = huc_to_i915(huc);
> + u32 status;
> +
> + if (!HAS_HUC(dev_priv))
> + return -ENODEV;
> +
> + intel_runtime_pm_get(dev_priv);
> + status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> + intel_runtime_pm_put(dev_priv);
> +
> + return status;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
> index b185850..aa85490 100644
> --- a/drivers/gpu/drm/i915/intel_huc.h
> +++ b/drivers/gpu/drm/i915/intel_huc.h
> @@ -37,6 +37,7 @@ struct intel_huc {
>
> void intel_huc_init_early(struct intel_huc *huc);
> int intel_huc_auth(struct intel_huc *huc);
> +int intel_huc_check_status(struct intel_huc *huc);
>
> static inline int intel_huc_sanitize(struct intel_huc *huc)
> {
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/huc: Check HuC status in dedicated function
2018-03-14 20:04 [PATCH] drm/i915/huc: Check HuC status in dedicated function Michal Wajdeczko
2018-03-14 20:17 ` Michel Thierry
@ 2018-03-14 20:58 ` Patchwork
2018-03-15 1:31 ` ✗ Fi.CI.IGT: failure " Patchwork
2 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2018-03-14 20:58 UTC (permalink / raw)
To: Michal Wajdeczko; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/huc: Check HuC status in dedicated function
URL : https://patchwork.freedesktop.org/series/39986/
State : success
== Summary ==
Series 39986v1 drm/i915/huc: Check HuC status in dedicated function
https://patchwork.freedesktop.org/api/1.0/series/39986/revisions/1/mbox/
---- Possible new issues:
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail -> PASS (fi-skl-6770hq)
---- Known issues:
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass -> INCOMPLETE (fi-snb-2520m) fdo#103713
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:431s
fi-bdw-gvtdvm total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:446s
fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:381s
fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:535s
fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s
fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:516s
fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:519s
fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:505s
fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s
fi-cfl-s2 total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:582s
fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:513s
fi-cnl-y3 total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:587s
fi-elk-e7500 total:285 pass:226 dwarn:0 dfail:0 fail:0 skip:59 time:427s
fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:318s
fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:540s
fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s
fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:424s
fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:475s
fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:429s
fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:480s
fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:467s
fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:514s
fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:651s
fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:440s
fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:530s
fi-skl-6700hq total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:544s
fi-skl-6700k2 total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:512s
fi-skl-6770hq total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:501s
fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s
fi-skl-gvtdvm total:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s
fi-snb-2520m total:242 pass:208 dwarn:0 dfail:0 fail:0 skip:33
fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:398s
Blacklisted hosts:
fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:545s
86e964296fe8bc85fdb624fa75b4cd83fcfb58cd drm-tip: 2018y-03m-14d-17h-40m-20s UTC integration manifest
d9e8e4b60d8c drm/i915/huc: Check HuC status in dedicated function
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8353/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915/huc: Check HuC status in dedicated function
2018-03-14 20:17 ` Michel Thierry
@ 2018-03-14 22:23 ` Michal Wajdeczko
2018-03-14 23:34 ` Michel Thierry
0 siblings, 1 reply; 7+ messages in thread
From: Michal Wajdeczko @ 2018-03-14 22:23 UTC (permalink / raw)
To: intel-gfx, Michel Thierry; +Cc: Rodrigo Vivi
On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry
<michel.thierry@intel.com> wrote:
> On 14/03/18 13:04, Michal Wajdeczko wrote:
>> We try to keep all HuC related code in dedicated file.
>> There is no need to peek HuC register directly during
>> handling getparam ioctl.
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Michel Thierry <michel.thierry@intel.com>
>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
>> drivers/gpu/drm/i915/intel_huc.c | 25 +++++++++++++++++++++++++
>> drivers/gpu/drm/i915/intel_huc.h | 1 +
>> 3 files changed, 29 insertions(+), 3 deletions(-)
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index f03555e..a902e88 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device
>> *dev, void *data,
>> value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
>> break;
>> case I915_PARAM_HUC_STATUS:
>> - intel_runtime_pm_get(dev_priv);
>> - value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
>> - intel_runtime_pm_put(dev_priv);
>> + value = intel_huc_check_status(&dev_priv->huc);
>> + if (value < 0)
>> + return value;
>> break;
>> case I915_PARAM_MMAP_GTT_VERSION:
>> /* Though we've started our numbering from 1, and so class all
>> diff --git a/drivers/gpu/drm/i915/intel_huc.c
>> b/drivers/gpu/drm/i915/intel_huc.c
>> index 1d6c47b..2912852 100644
>> --- a/drivers/gpu/drm/i915/intel_huc.c
>> +++ b/drivers/gpu/drm/i915/intel_huc.c
>> @@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
>> DRM_ERROR("HuC: Authentication failed %d\n", ret);
>> return ret;
>> }
>> +
>> +/**
>> + * intel_huc_check_status() - check HuC status
>> + * @huc: intel_huc structure
>> + *
>> + * This function reads status register to verify if HuC
>> + * firmware was successfully loaded.
>> + *
>> + * Returns positive value if HuC firmware is loaded and verified
>> + * and -ENODEV if HuC is not present.
>
> Before if huc was not loaded, get_param would just return 0 and the
> ioctl call would be OK.
There is another potential problem, as in case HuC was loaded, this
getparam would return specific bit from register instead of predefined
value that shall indicate "loaded/verified" like "1".
What if this bit from register will be moved on future platforms?
Should we still return this old one?
> Maybe there's a test somewhere that would break?
I hope not, and given above concern, I assume we can still modify it.
Is there any documentation what to expect from this getparam?
> (I'm not arguing -ENODEV is better).
In all other places (like debugfs) we return -ENODEV if user wants
to access HuC data on platform without HuC, so I think we should be
consistent.
>
> Otherwise,
>
> Reviewed-by: Michel Thierry <michel.thierry@intel.com>
>
>> + */
>> +int intel_huc_check_status(struct intel_huc *huc)
>> +{
>> + struct drm_i915_private *dev_priv = huc_to_i915(huc);
>> + u32 status;
>> +
>> + if (!HAS_HUC(dev_priv))
>> + return -ENODEV;
>> +
>> + intel_runtime_pm_get(dev_priv);
>> + status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
>> + intel_runtime_pm_put(dev_priv);
>> +
>> + return status;
>> +}
>> diff --git a/drivers/gpu/drm/i915/intel_huc.h
>> b/drivers/gpu/drm/i915/intel_huc.h
>> index b185850..aa85490 100644
>> --- a/drivers/gpu/drm/i915/intel_huc.h
>> +++ b/drivers/gpu/drm/i915/intel_huc.h
>> @@ -37,6 +37,7 @@ struct intel_huc {
>> void intel_huc_init_early(struct intel_huc *huc);
>> int intel_huc_auth(struct intel_huc *huc);
>> +int intel_huc_check_status(struct intel_huc *huc);
>> static inline int intel_huc_sanitize(struct intel_huc *huc)
>> {
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915/huc: Check HuC status in dedicated function
2018-03-14 22:23 ` Michal Wajdeczko
@ 2018-03-14 23:34 ` Michel Thierry
2018-03-21 15:15 ` Chris Wilson
0 siblings, 1 reply; 7+ messages in thread
From: Michel Thierry @ 2018-03-14 23:34 UTC (permalink / raw)
To: Michal Wajdeczko, intel-gfx; +Cc: Rodrigo Vivi
On 14/03/18 15:23, Michal Wajdeczko wrote:
> On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry
> <michel.thierry@intel.com> wrote:
>
>> On 14/03/18 13:04, Michal Wajdeczko wrote:
>>> We try to keep all HuC related code in dedicated file.
>>> There is no need to peek HuC register directly during
>>> handling getparam ioctl.
>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>> Cc: Michel Thierry <michel.thierry@intel.com>
>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
>>> drivers/gpu/drm/i915/intel_huc.c | 25 +++++++++++++++++++++++++
>>> drivers/gpu/drm/i915/intel_huc.h | 1 +
>>> 3 files changed, 29 insertions(+), 3 deletions(-)
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>>> b/drivers/gpu/drm/i915/i915_drv.c
>>> index f03555e..a902e88 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.c
>>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>>> @@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device
>>> *dev, void *data,
>>> value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
>>> break;
>>> case I915_PARAM_HUC_STATUS:
>>> - intel_runtime_pm_get(dev_priv);
>>> - value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
>>> - intel_runtime_pm_put(dev_priv);
>>> + value = intel_huc_check_status(&dev_priv->huc);
>>> + if (value < 0)
>>> + return value;
>>> break;
>>> case I915_PARAM_MMAP_GTT_VERSION:
>>> /* Though we've started our numbering from 1, and so class all
>>> diff --git a/drivers/gpu/drm/i915/intel_huc.c
>>> b/drivers/gpu/drm/i915/intel_huc.c
>>> index 1d6c47b..2912852 100644
>>> --- a/drivers/gpu/drm/i915/intel_huc.c
>>> +++ b/drivers/gpu/drm/i915/intel_huc.c
>>> @@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
>>> DRM_ERROR("HuC: Authentication failed %d\n", ret);
>>> return ret;
>>> }
>>> +
>>> +/**
>>> + * intel_huc_check_status() - check HuC status
>>> + * @huc: intel_huc structure
>>> + *
>>> + * This function reads status register to verify if HuC
>>> + * firmware was successfully loaded.
>>> + *
>>> + * Returns positive value if HuC firmware is loaded and verified
>>> + * and -ENODEV if HuC is not present.
>>
>> Before if huc was not loaded, get_param would just return 0 and the
>> ioctl call would be OK.
>
> There is another potential problem, as in case HuC was loaded, this
> getparam would return specific bit from register instead of predefined
> value that shall indicate "loaded/verified" like "1".
> What if this bit from register will be moved on future platforms?
Really? ;)
I once heard someone claiming he had talked with the hw team and they've
agreed not to randomly shuffle register specifications
(please laugh with me).
> Should we still return this old one?
>
>> Maybe there's a test somewhere that would break?
>
> I hope not, and given above concern, I assume we can still modify it.
> Is there any documentation what to expect from this getparam?
>
And the media driver would survive the change [1] if that's what we care
about.
But is the response from getparam ABI? I would say just
drm_i915_getparam_t is.
[1]
https://github.com/intel/media-driver/blob/c0321bc88e12247d21fa2d0b470cff841c3712ba/media_driver/linux/common/os/hwinfo_linux.c#L254
>> (I'm not arguing -ENODEV is better).
>
> In all other places (like debugfs) we return -ENODEV if user wants
> to access HuC data on platform without HuC, so I think we should be
> consistent.
>
sorry, a missing comma... I was agreeing with you:
>> (I'm not arguing, -ENODEV is better).
>>
>> Otherwise,
>>
>> Reviewed-by: Michel Thierry <michel.thierry@intel.com>
>>
>>> + */
>>> +int intel_huc_check_status(struct intel_huc *huc)
>>> +{
>>> + struct drm_i915_private *dev_priv = huc_to_i915(huc);
>>> + u32 status;
>>> +
>>> + if (!HAS_HUC(dev_priv))
>>> + return -ENODEV;
>>> +
>>> + intel_runtime_pm_get(dev_priv);
>>> + status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
>>> + intel_runtime_pm_put(dev_priv);
>>> +
>>> + return status;
>>> +}
>>> diff --git a/drivers/gpu/drm/i915/intel_huc.h
>>> b/drivers/gpu/drm/i915/intel_huc.h
>>> index b185850..aa85490 100644
>>> --- a/drivers/gpu/drm/i915/intel_huc.h
>>> +++ b/drivers/gpu/drm/i915/intel_huc.h
>>> @@ -37,6 +37,7 @@ struct intel_huc {
>>> void intel_huc_init_early(struct intel_huc *huc);
>>> int intel_huc_auth(struct intel_huc *huc);
>>> +int intel_huc_check_status(struct intel_huc *huc);
>>> static inline int intel_huc_sanitize(struct intel_huc *huc)
>>> {
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* ✗ Fi.CI.IGT: failure for drm/i915/huc: Check HuC status in dedicated function
2018-03-14 20:04 [PATCH] drm/i915/huc: Check HuC status in dedicated function Michal Wajdeczko
2018-03-14 20:17 ` Michel Thierry
2018-03-14 20:58 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2018-03-15 1:31 ` Patchwork
2 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2018-03-15 1:31 UTC (permalink / raw)
To: Michal Wajdeczko; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/huc: Check HuC status in dedicated function
URL : https://patchwork.freedesktop.org/series/39986/
State : failure
== Summary ==
---- Possible new issues:
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-pwrite:
pass -> FAIL (shard-apl)
---- Known issues:
Test drv_suspend:
Subgroup debugfs-reader:
pass -> SKIP (shard-snb) fdo#102365
Test gem_eio:
Subgroup in-flight-external:
incomplete -> PASS (shard-apl) fdo#105341 +1
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
fail -> PASS (shard-hsw) fdo#100368 +1
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
shard-apl total:3401 pass:1789 dwarn:1 dfail:0 fail:8 skip:1601 time:12464s
shard-hsw total:3441 pass:1766 dwarn:1 dfail:0 fail:1 skip:1672 time:11873s
shard-snb total:3441 pass:1354 dwarn:1 dfail:0 fail:3 skip:2083 time:7129s
Blacklisted hosts:
shard-kbl total:3425 pass:1925 dwarn:1 dfail:0 fail:9 skip:1488 time:9137s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8353/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915/huc: Check HuC status in dedicated function
2018-03-14 23:34 ` Michel Thierry
@ 2018-03-21 15:15 ` Chris Wilson
0 siblings, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2018-03-21 15:15 UTC (permalink / raw)
To: Michel Thierry, Michal Wajdeczko, intel-gfx; +Cc: Rodrigo Vivi
Quoting Michel Thierry (2018-03-14 23:34:33)
> On 14/03/18 15:23, Michal Wajdeczko wrote:
> > On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry
> > <michel.thierry@intel.com> wrote:
> >
> >> On 14/03/18 13:04, Michal Wajdeczko wrote:
> >>> We try to keep all HuC related code in dedicated file.
> >>> There is no need to peek HuC register directly during
> >>> handling getparam ioctl.
> >>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>> Cc: Michel Thierry <michel.thierry@intel.com>
> >>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> >>> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
> >>> ---
> >>> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
> >>> drivers/gpu/drm/i915/intel_huc.c | 25 +++++++++++++++++++++++++
> >>> drivers/gpu/drm/i915/intel_huc.h | 1 +
> >>> 3 files changed, 29 insertions(+), 3 deletions(-)
> >>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> >>> b/drivers/gpu/drm/i915/i915_drv.c
> >>> index f03555e..a902e88 100644
> >>> --- a/drivers/gpu/drm/i915/i915_drv.c
> >>> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >>> @@ -377,9 +377,9 @@ static int i915_getparam_ioctl(struct drm_device
> >>> *dev, void *data,
> >>> value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
> >>> break;
> >>> case I915_PARAM_HUC_STATUS:
> >>> - intel_runtime_pm_get(dev_priv);
> >>> - value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
> >>> - intel_runtime_pm_put(dev_priv);
> >>> + value = intel_huc_check_status(&dev_priv->huc);
> >>> + if (value < 0)
> >>> + return value;
> >>> break;
> >>> case I915_PARAM_MMAP_GTT_VERSION:
> >>> /* Though we've started our numbering from 1, and so class all
> >>> diff --git a/drivers/gpu/drm/i915/intel_huc.c
> >>> b/drivers/gpu/drm/i915/intel_huc.c
> >>> index 1d6c47b..2912852 100644
> >>> --- a/drivers/gpu/drm/i915/intel_huc.c
> >>> +++ b/drivers/gpu/drm/i915/intel_huc.c
> >>> @@ -92,3 +92,28 @@ int intel_huc_auth(struct intel_huc *huc)
> >>> DRM_ERROR("HuC: Authentication failed %d\n", ret);
> >>> return ret;
> >>> }
> >>> +
> >>> +/**
> >>> + * intel_huc_check_status() - check HuC status
> >>> + * @huc: intel_huc structure
> >>> + *
> >>> + * This function reads status register to verify if HuC
> >>> + * firmware was successfully loaded.
> >>> + *
> >>> + * Returns positive value if HuC firmware is loaded and verified
> >>> + * and -ENODEV if HuC is not present.
> >>
> >> Before if huc was not loaded, get_param would just return 0 and the
> >> ioctl call would be OK.
> >
> > There is another potential problem, as in case HuC was loaded, this
> > getparam would return specific bit from register instead of predefined
> > value that shall indicate "loaded/verified" like "1".
> > What if this bit from register will be moved on future platforms?
>
> Really? ;)
> I once heard someone claiming he had talked with the hw team and they've
> agreed not to randomly shuffle register specifications
> (please laugh with me).
>
> > Should we still return this old one?
> >
> >> Maybe there's a test somewhere that would break?
> >
> > I hope not, and given above concern, I assume we can still modify it.
> > Is there any documentation what to expect from this getparam?
> >
>
> And the media driver would survive the change [1] if that's what we care
> about.
>
> But is the response from getparam ABI? I would say just
> drm_i915_getparam_t is.
So long as we obey the rule to not overwrite on error, we should be
within the existing ABI. Then we only have the argument over what errno
suits the ABI.
-ENODEV is what we have been using for a user call for a function not
supported by the HW, so fine by me.
Pushed, thanks for the patch and review.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-03-21 15:15 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-14 20:04 [PATCH] drm/i915/huc: Check HuC status in dedicated function Michal Wajdeczko
2018-03-14 20:17 ` Michel Thierry
2018-03-14 22:23 ` Michal Wajdeczko
2018-03-14 23:34 ` Michel Thierry
2018-03-21 15:15 ` Chris Wilson
2018-03-14 20:58 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-03-15 1:31 ` ✗ Fi.CI.IGT: failure " Patchwork
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox