diff mbox

[09/15] drm/i915/guc: Move check for fast memcpy_wc to relay creation

Message ID 20180227125230.13000-9-michal.winiarski@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Michał Winiarski Feb. 27, 2018, 12:52 p.m. UTC
We only need those fast memcpy_wc when we're using relay to read
continuous GuC log. Let's prevent the user from creating a relay if we
know we won't be able to keep up with GuC.

Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
---
 drivers/gpu/drm/i915/intel_guc_log.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

Comments

Michal Wajdeczko Feb. 27, 2018, 2:37 p.m. UTC | #1
On Tue, 27 Feb 2018 13:52:24 +0100, Michał Winiarski  
<michal.winiarski@intel.com> wrote:

> We only need those fast memcpy_wc when we're using relay to read
> continuous GuC log. Let's prevent the user from creating a relay if we
> know we won't be able to keep up with GuC.
>
> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_guc_log.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_log.c  
> b/drivers/gpu/drm/i915/intel_guc_log.c
> index 4dee65692f5f..d2aca10ab986 100644
> --- a/drivers/gpu/drm/i915/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> @@ -452,16 +452,6 @@ int intel_guc_log_create(struct intel_guc *guc)
> 	GEM_BUG_ON(guc->log.vma);
> -	/*
> -	 * We require SSE 4.1 for fast reads from the GuC log buffer and
> -	 * it should be present on the chipsets supporting GuC based
> -	 * submisssions.
> -	 */
> -	if (WARN_ON(!i915_has_memcpy_from_wc())) {
> -		ret = -EINVAL;
> -		goto err;
> -	}
> -
>  	vma = intel_guc_allocate_vma(guc, GUC_LOG_SIZE);
>  	if (IS_ERR(vma)) {
>  		ret = PTR_ERR(vma);
> @@ -568,6 +558,16 @@ int intel_guc_log_relay_open(struct intel_guc *guc)
>  		goto out_unlock;
>  	}
> +	/*
> +	 * We require SSE 4.1 for fast reads from the GuC log buffer and
> +	 * it should be present on the chipsets supporting GuC based
> +	 * submisssions.
> +	 */
> +	if (!i915_has_memcpy_from_wc()) {
> +		ret = -EINVAL;

hmm, maybe -ENODEV as this is not user fault

> +		goto out_unlock;
> +	}
> +
>  	ret = guc_log_relay_create(guc);
>  	if (ret)
>  		goto out_unlock;
Michał Winiarski Feb. 27, 2018, 3:37 p.m. UTC | #2
On Tue, Feb 27, 2018 at 03:37:25PM +0100, Michal Wajdeczko wrote:
> On Tue, 27 Feb 2018 13:52:24 +0100, Michał Winiarski
> <michal.winiarski@intel.com> wrote:
> 
> > We only need those fast memcpy_wc when we're using relay to read
> > continuous GuC log. Let's prevent the user from creating a relay if we
> > know we won't be able to keep up with GuC.
> > 
> > Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_guc_log.c | 20 ++++++++++----------
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
> > b/drivers/gpu/drm/i915/intel_guc_log.c
> > index 4dee65692f5f..d2aca10ab986 100644
> > --- a/drivers/gpu/drm/i915/intel_guc_log.c
> > +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> > @@ -452,16 +452,6 @@ int intel_guc_log_create(struct intel_guc *guc)
> > 	GEM_BUG_ON(guc->log.vma);
> > -	/*
> > -	 * We require SSE 4.1 for fast reads from the GuC log buffer and
> > -	 * it should be present on the chipsets supporting GuC based
> > -	 * submisssions.
> > -	 */
> > -	if (WARN_ON(!i915_has_memcpy_from_wc())) {
> > -		ret = -EINVAL;
> > -		goto err;
> > -	}
> > -
> >  	vma = intel_guc_allocate_vma(guc, GUC_LOG_SIZE);
> >  	if (IS_ERR(vma)) {
> >  		ret = PTR_ERR(vma);
> > @@ -568,6 +558,16 @@ int intel_guc_log_relay_open(struct intel_guc *guc)
> >  		goto out_unlock;
> >  	}
> > +	/*
> > +	 * We require SSE 4.1 for fast reads from the GuC log buffer and
> > +	 * it should be present on the chipsets supporting GuC based
> > +	 * submisssions.
> > +	 */
> > +	if (!i915_has_memcpy_from_wc()) {
> > +		ret = -EINVAL;
> 
> hmm, maybe -ENODEV as this is not user fault

ENODEV means that we're not using GuC.
-ENXIO?

-Michał

> 
> > +		goto out_unlock;
> > +	}
> > +
> >  	ret = guc_log_relay_create(guc);
> >  	if (ret)
> >  		goto out_unlock;
sagar.a.kamble@intel.com March 6, 2018, 7:23 a.m. UTC | #3
On 2/27/2018 6:22 PM, Michał Winiarski wrote:
> We only need those fast memcpy_wc when we're using relay to read
> continuous GuC log. Let's prevent the user from creating a relay if we
> know we won't be able to keep up with GuC.
>
> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> ---
>   drivers/gpu/drm/i915/intel_guc_log.c | 20 ++++++++++----------
>   1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c
> index 4dee65692f5f..d2aca10ab986 100644
> --- a/drivers/gpu/drm/i915/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> @@ -452,16 +452,6 @@ int intel_guc_log_create(struct intel_guc *guc)
>   
>   	GEM_BUG_ON(guc->log.vma);
>   
> -	/*
> -	 * We require SSE 4.1 for fast reads from the GuC log buffer and
> -	 * it should be present on the chipsets supporting GuC based
> -	 * submisssions.
> -	 */
> -	if (WARN_ON(!i915_has_memcpy_from_wc())) {
> -		ret = -EINVAL;
> -		goto err;
> -	}
> -
>   	vma = intel_guc_allocate_vma(guc, GUC_LOG_SIZE);
>   	if (IS_ERR(vma)) {
>   		ret = PTR_ERR(vma);
> @@ -568,6 +558,16 @@ int intel_guc_log_relay_open(struct intel_guc *guc)
>   		goto out_unlock;
>   	}
>   
> +	/*
> +	 * We require SSE 4.1 for fast reads from the GuC log buffer and
> +	 * it should be present on the chipsets supporting GuC based
> +	 * submisssions.
> +	 */
> +	if (!i915_has_memcpy_from_wc()) {
> +		ret = -EINVAL;
> +		goto out_unlock;
> +	}
> +
>   	ret = guc_log_relay_create(guc);
>   	if (ret)
>   		goto out_unlock;
Chris Wilson March 6, 2018, 2 p.m. UTC | #4
Quoting Michał Winiarski (2018-02-27 15:37:04)
> On Tue, Feb 27, 2018 at 03:37:25PM +0100, Michal Wajdeczko wrote:
> > On Tue, 27 Feb 2018 13:52:24 +0100, Michał Winiarski
> > <michal.winiarski@intel.com> wrote:
> > 
> > > We only need those fast memcpy_wc when we're using relay to read
> > > continuous GuC log. Let's prevent the user from creating a relay if we
> > > know we won't be able to keep up with GuC.
> > > 
> > > Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > > Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> > > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_guc_log.c | 20 ++++++++++----------
> > >  1 file changed, 10 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
> > > b/drivers/gpu/drm/i915/intel_guc_log.c
> > > index 4dee65692f5f..d2aca10ab986 100644
> > > --- a/drivers/gpu/drm/i915/intel_guc_log.c
> > > +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> > > @@ -452,16 +452,6 @@ int intel_guc_log_create(struct intel_guc *guc)
> > >     GEM_BUG_ON(guc->log.vma);
> > > -   /*
> > > -    * We require SSE 4.1 for fast reads from the GuC log buffer and
> > > -    * it should be present on the chipsets supporting GuC based
> > > -    * submisssions.
> > > -    */
> > > -   if (WARN_ON(!i915_has_memcpy_from_wc())) {
> > > -           ret = -EINVAL;
> > > -           goto err;
> > > -   }
> > > -
> > >     vma = intel_guc_allocate_vma(guc, GUC_LOG_SIZE);
> > >     if (IS_ERR(vma)) {
> > >             ret = PTR_ERR(vma);
> > > @@ -568,6 +558,16 @@ int intel_guc_log_relay_open(struct intel_guc *guc)
> > >             goto out_unlock;
> > >     }
> > > +   /*
> > > +    * We require SSE 4.1 for fast reads from the GuC log buffer and
> > > +    * it should be present on the chipsets supporting GuC based
> > > +    * submisssions.
> > > +    */
> > > +   if (!i915_has_memcpy_from_wc()) {
> > > +           ret = -EINVAL;
> > 
> > hmm, maybe -ENODEV as this is not user fault
> 
> ENODEV means that we're not using GuC.
> -ENXIO?

Do we respond to the error at all? It should just result in the relay
not being available, right?

(i.e. are we just discussing the color of the bikeshed :)
-Chris
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c
index 4dee65692f5f..d2aca10ab986 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -452,16 +452,6 @@  int intel_guc_log_create(struct intel_guc *guc)
 
 	GEM_BUG_ON(guc->log.vma);
 
-	/*
-	 * We require SSE 4.1 for fast reads from the GuC log buffer and
-	 * it should be present on the chipsets supporting GuC based
-	 * submisssions.
-	 */
-	if (WARN_ON(!i915_has_memcpy_from_wc())) {
-		ret = -EINVAL;
-		goto err;
-	}
-
 	vma = intel_guc_allocate_vma(guc, GUC_LOG_SIZE);
 	if (IS_ERR(vma)) {
 		ret = PTR_ERR(vma);
@@ -568,6 +558,16 @@  int intel_guc_log_relay_open(struct intel_guc *guc)
 		goto out_unlock;
 	}
 
+	/*
+	 * We require SSE 4.1 for fast reads from the GuC log buffer and
+	 * it should be present on the chipsets supporting GuC based
+	 * submisssions.
+	 */
+	if (!i915_has_memcpy_from_wc()) {
+		ret = -EINVAL;
+		goto out_unlock;
+	}
+
 	ret = guc_log_relay_create(guc);
 	if (ret)
 		goto out_unlock;