public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
* [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