All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH] RFC drm/i915: Put future HW and their uAPIs under STAGING & BROKEN
Date: Thu, 29 Aug 2019 15:19:23 -0700	[thread overview]
Message-ID: <20190829221923.GA5714@intel.com> (raw)
In-Reply-To: <20190829121722.13701-1-chris@chris-wilson.co.uk>

On Thu, Aug 29, 2019 at 01:17:22PM +0100, Chris Wilson wrote:
> We would like some freedom to break the user API/ABI for future HW but
> yet still expose the driver for upstream development on that HW.
> Currently, we have the i915.force_probe module parameter to avoid binding
> to HW while the driver is under development, but that is still a little
> too soft with respect to the stringent no-regression rules if we also
> plan to be redesigning the uAPI to go along with the new HW.
> 
> To allow the uAPI to be changed during development, only expose that API
> and in development HW under STAGING (and BROKEN). Hopefully, making it
> explicit that such interfaces to that HW are under development and not
> to be blindly enabled by distributions.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Dave Airlie <airlied@redhat.com>
> ---
>  drivers/gpu/drm/i915/Kconfig.debug       | 15 +++++++++++++++
>  drivers/gpu/drm/i915/i915_gem.c          | 10 ++++++++++
>  drivers/gpu/drm/i915/intel_device_info.h |  1 +
>  3 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug
> index 00786a142ff0..7707d1230b85 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -36,6 +36,9 @@ config DRM_I915_DEBUG
>  	select DRM_I915_SELFTEST
>  	select DRM_I915_DEBUG_RUNTIME_PM
>  	select DRM_I915_DEBUG_MMIO
> +	select STAGING
> +	select BROKEN
> +	select DRM_I915_DEBUG_EARLY_API

I'm not sure about forcing this all all debug.

>          default n
>          help
>            Choose this option to turn on extra driver debugging that may affect
> @@ -212,3 +215,15 @@ config DRM_I915_DEBUG_RUNTIME_PM
>  	  driver loading, suspend and resume operations.
>  
>  	  If in doubt, say "N"
> +
> +config DRM_I915_DEBUG_EARLY_API
> +	bool "Expose new HW uAPIs for early testing"
> +	depends on DRM_I915
> +	depends on STAGING
> +	depends on BROKEN

instead why not
select STAGING
select BROKEN
depends on DRM_I915_DEBUG

?

> +	default n
> +	help
> +	  Expose in-development uAPI for early testing on HW. Such uAPI
> +	  will likely subtly change before release and must not be relied upon.
> +
> +	  If in doubt, say "N"
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index bb39c64a0a17..eab2219d7a50 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1344,6 +1344,15 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
>  {
>  	int ret;
>  
> +	if (INTEL_INFO(dev_priv)->early_render_uapi) {
> +		if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_EARLY_API)) {
> +			ret = -EIO;
> +			goto err_disable;
> +		}
> +
> +		add_taint(TAINT_USER, LOCKDEP_STILL_OK);
> +	}
> +
>  	/* We need to fallback to 4K pages if host doesn't support huge gtt. */
>  	if (intel_vgpu_active(dev_priv) && !intel_vgpu_has_huge_gtt(dev_priv))
>  		mkwrite_device_info(dev_priv)->page_sizes =
> @@ -1476,6 +1485,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
>  		intel_timelines_fini(dev_priv);
>  	}
>  
> +err_disable:
>  	if (ret == -EIO) {
>  		/*
>  		 * Allow engines or uC initialisation to fail by marking the GPU
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h
> index 92e0c2e0954c..5931f619e66b 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -107,6 +107,7 @@ enum intel_ppgtt_type {
>  	func(is_mobile); \
>  	func(is_lp); \
>  	func(require_force_probe); \
> +	func(early_render_uapi); \
>  	/* Keep has_* in alphabetical order */ \
>  	func(has_64bit_reloc); \
>  	func(gpu_reset_clobbers_display); \
> -- 
> 2.23.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

      parent reply	other threads:[~2019-08-29 22:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29 12:17 [PATCH] RFC drm/i915: Put future HW and their uAPIs under STAGING & BROKEN Chris Wilson
2019-08-29 13:03 ` ✗ Fi.CI.BAT: failure for " Patchwork
2019-08-29 22:19 ` Rodrigo Vivi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190829221923.GA5714@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=airlied@redhat.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.