Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Sharma, Shashank" <shashank.sharma@intel.com>
To: Animesh Manna <animesh.manna@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Michel Thierry <michel.thierry@intel.com>,
	Jani Nikula <jani.nikula@intel.com>
Subject: Re: [PATCH v3 02/11] drm/i915/dsb: DSB context creation.
Date: Wed, 28 Aug 2019 20:09:43 +0530	[thread overview]
Message-ID: <c9876362-5377-f73b-16ca-0de5122e7983@intel.com> (raw)
In-Reply-To: <20190827191026.26175-3-animesh.manna@intel.com>


On 8/28/2019 12:40 AM, Animesh Manna wrote:
> The function will internally get the gem buffer from global GTT
This patch adds a function, which will internally get the gem buffer for 
DSB engine.
> which is mapped in cpu domain to feed the data + opcode for DSB engine.
This GEM buffer is from global GTT, and is mapped into CPU domain, 
contains the data + opcode to be fed to DSB engine.
>
> v1: initial version.
>
> v2:
> - removed some unwanted code. (Chris)
> - Used i915_gem_object_create_internal instead of _shmem. (Chris)
> - cmd_buf_tail removed and can be derived through vma object. (Chris)
>
> Cc: Imre Deak <imre.deak@intel.com>
> Cc: Michel Thierry <michel.thierry@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Signed-off-by: Animesh Manna <animesh.manna@intel.com>
> ---
>   drivers/gpu/drm/i915/Makefile                 |  1 +
>   .../drm/i915/display/intel_display_types.h    |  3 +
>   drivers/gpu/drm/i915/display/intel_dsb.c      | 83 +++++++++++++++++++
>   drivers/gpu/drm/i915/display/intel_dsb.h      | 31 +++++++
>   drivers/gpu/drm/i915/i915_drv.h               |  1 +
>   5 files changed, 119 insertions(+)
>   create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.c
>   create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 658b930d34a8..6313e7b4bd78 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -172,6 +172,7 @@ i915-y += \
>   	display/intel_display_power.o \
>   	display/intel_dpio_phy.o \
>   	display/intel_dpll_mgr.o \
> +	display/intel_dsb.o \
>   	display/intel_fbc.o \
>   	display/intel_fifo_underrun.o \
>   	display/intel_frontbuffer.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 96514dcc7812..0ab3516b0044 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1026,6 +1026,9 @@ struct intel_crtc {
>   
>   	/* scalers available on this crtc */
>   	int num_scalers;
> +
> +	/* per pipe DSB related info */
> +	struct intel_dsb dsb[MAX_DSB_PER_PIPE];
>   };
>   
>   struct intel_plane {
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c b/drivers/gpu/drm/i915/display/intel_dsb.c
> new file mode 100644
> index 000000000000..a2845df90573
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -0,0 +1,83 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2019 Intel Corporation
> + *
> + */
> +
Any particular reason we don't have the traditional license here, like 
other files ?
> +#include "../i915_drv.h"
This is not the way you should include this header. Take example from 
other files in display folder.
> +#include "intel_display_types.h"
> +
> +#define DSB_BUF_SIZE    (2 * PAGE_SIZE)
Any particular reason for this size ?
> +
> +struct intel_dsb *
> +intel_dsb_get(struct intel_crtc *crtc)
> +{
> +	struct drm_device *dev = crtc->base.dev;
> +	struct drm_i915_private *i915 = to_i915(dev);
> +	struct drm_i915_gem_object *obj;
> +	struct i915_vma *vma;
> +	struct intel_dsb *dsb;
> +	intel_wakeref_t wakeref;
> +	int i;
> +
> +	for (i = 0; i < MAX_DSB_PER_PIPE; i++)
> +		if (!crtc->dsb[i].cmd_buf)
> +			break;
> +
> +	WARN_ON(i >= MAX_DSB_PER_PIPE);

Its not possible to have i > MAX_DSB_PER_PIPE as per above logic, so it 
should be WARN_ON(i == MAX_DSB_PER_PIPE);

Also, shouldn't we stop operation here (along with the warning) as 
clearly the cmd_buf and dsb we are going to get, is garbage ? On 
negative testing this may cause kernel panic also.

> +
> +	dsb = &crtc->dsb[i];
> +	dsb->id = i;
> +	dsb->crtc = crtc;
> +	if (!HAS_DSB(i915))
> +		return dsb;
This check should be the first line in this function. I am not sure why 
do we want to extract dsb ptr if the platform doesn't even support DSB.
> +
> +	wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> +
> +	obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
> +	if (IS_ERR(obj))
> +		goto err;
> +
> +	mutex_lock(&i915->drm.struct_mutex);
> +	vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);
> +	mutex_unlock(&i915->drm.struct_mutex);
> +	if (IS_ERR(vma)) {
> +		DRM_DEBUG_KMS("Vma creation failed.\n");
> +		i915_gem_object_put(obj);
Shouldn't gem_object_put() be inside mutex ?
> +		goto err;
> +	}
> +
> +	dsb->cmd_buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
> +	if (IS_ERR(dsb->cmd_buf)) {
> +		DRM_DEBUG_KMS("Command buffer creation failed.\n");
> +		dsb->cmd_buf = NULL;
Why don't we have a i915_gem_object_put(obj) here ?
> +		goto err;
> +	}
> +	dsb->vma = vma;
> +
> +err:
I think we should have a i915_gem_object_put(obj) for all error cases here.
> +	intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> +	return dsb;
Again, we are returning a dsb ptr in all cases. As this patch doesn't 
have the caller function, I can't understand why are we returning the 
same ptr in both success or failure cases, but I would prefer a 
dsb_get() function which returns NULL on failure, dsb* on success.
> +}
> +
> +void intel_dsb_put(struct intel_dsb *dsb)
> +{
> +	struct intel_crtc *crtc;
> +	struct drm_i915_private *i915;
> +	struct i915_vma *vma;
> +
> +	if (!dsb)
> +		return;
So the get() API returns a non-NULL pointer in both success and failure 
cases, but put() can have a NULL ptr as input. Looks a bit asymmetrical  
design. Also, we should add API documentation on top of the function 
now, as we need to understand what can be the return values of the 
function.
> +
> +	crtc = dsb->crtc;
> +	i915 = to_i915(crtc->base.dev);
> +
> +	if (dsb->cmd_buf) {
> +		vma = dsb->vma;
> +		mutex_lock(&i915->drm.struct_mutex);
> +		i915_gem_object_unpin_map(vma->obj);
> +		i915_vma_unpin_and_release(&vma, 0);
> +		dsb->cmd_buf = NULL;
> +		mutex_unlock(&i915->drm.struct_mutex);
> +	}
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h b/drivers/gpu/drm/i915/display/intel_dsb.h
> new file mode 100644
> index 000000000000..4a4091cadc1e
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.h
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: MIT
> + *
> + * Copyright © 2019 Intel Corporation
Same as above for license.
> + */
> +
> +#ifndef _INTEL_DSB_H
> +#define _INTEL_DSB_H
> +
> +struct intel_crtc;
> +struct i915_vma;
> +
> +enum dsb_id {
> +	INVALID_DSB = -1,
> +	DSB1,
> +	DSB2,
> +	DSB3,
> +	MAX_DSB_PER_PIPE
The Bspec says there are 3 DSB DMA engines per pipe, and we have defined 
MAX_DSB_PER_PIPE = 3 (and the count starts from 0), which means we 
should be running our loops always < MAX_DSB_PER_PIPE. I would prefer 
this to be either INVALID_DSB = 0 and DSB3 = MAX_DSB = 3, but this is 
just a soft requirement, you can pick or ignore.
> +};
> +
> +struct intel_dsb {
> +	struct intel_crtc *crtc;
> +	enum dsb_id id;
Note that your INVALID_DSB id is -1 not 0. This means all the intel_dsb 
structures will be initialized with id=DSB1 not INVALID_DSB.
> +	u32 *cmd_buf;
> +	struct i915_vma *vma;
> +};
> +
This could also be the place to add doc about the get/put functions.
> +struct intel_dsb *
> +intel_dsb_get(struct intel_crtc *crtc);
> +void intel_dsb_put(struct intel_dsb *dsb);

> +
> +#endif
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d32cfdb78b74..dd6cfb89b830 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -67,6 +67,7 @@
>   #include "display/intel_display.h"
>   #include "display/intel_display_power.h"
>   #include "display/intel_dpll_mgr.h"
> +#include "display/intel_dsb.h"

No external element is using get() / put() functions yet, this change 
should go into a patch, which is using the functions.

- Shashank

>   #include "display/intel_frontbuffer.h"
>   #include "display/intel_gmbus.h"
>   #include "display/intel_opregion.h"
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-08-28 14:39 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-27 19:10 [PATCH v3 00/11] DSB enablement Animesh Manna
2019-08-27 19:10 ` [PATCH v3 01/11] drm/i915/dsb: feature flag added for display state buffer Animesh Manna
2019-08-28 14:01   ` Sharma, Shashank
2019-08-29  7:10     ` Animesh Manna
2019-08-27 19:10 ` [PATCH v3 02/11] drm/i915/dsb: DSB context creation Animesh Manna
2019-08-28 14:39   ` Sharma, Shashank [this message]
2019-08-29 10:40     ` Animesh Manna
2019-08-27 19:10 ` [PATCH v3 03/11] drm/i915/dsb: single register write function for DSB Animesh Manna
2019-08-28 15:16   ` Sharma, Shashank
2019-08-29 13:09     ` Animesh Manna
2019-08-27 19:10 ` [PATCH v3 04/11] drm/i915/dsb: Indexed " Animesh Manna
2019-08-28 16:46   ` Sharma, Shashank
2019-08-29 13:23     ` Animesh Manna
2019-08-27 19:10 ` [PATCH v3 05/11] drm/i915/dsb: Register definition of DSB registers Animesh Manna
2019-08-28 17:02   ` Sharma, Shashank
2019-08-29 13:24     ` Animesh Manna
2019-08-27 19:10 ` [PATCH v3 06/11] drm/i915/dsb: Check DSB engine status Animesh Manna
2019-08-27 19:10 ` [PATCH v3 07/11] drm/i915/dsb: functions to enable/disable DSB engine Animesh Manna
2019-08-28 17:07   ` Sharma, Shashank
2019-08-29 13:45     ` Animesh Manna
2019-08-27 19:10 ` [PATCH v3 08/11] drm/i915/dsb: function to trigger workload execution of DSB Animesh Manna
2019-08-28 17:21   ` Sharma, Shashank
2019-08-27 19:10 ` [PATCH v3 09/11] drm/i915/dsb: Documentation for DSB Animesh Manna
2019-08-28 17:23   ` Sharma, Shashank
2019-08-27 19:10 ` [PATCH v3 10/11] drm/i915/dsb: Enable gamma lut programming using DSB Animesh Manna
2019-08-28 18:15   ` Sharma, Shashank
2019-08-29 13:48     ` Animesh Manna
2019-08-27 19:10 ` [PATCH v3 11/11] drm/i915/dsb: Enable DSB for gen12 Animesh Manna
2019-08-27 19:44 ` ✗ Fi.CI.CHECKPATCH: warning for DSB enablement. (rev3) Patchwork
2019-08-27 19:45 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-08-27 20:11 ` ✓ Fi.CI.BAT: success " Patchwork
2019-08-29  9:17 ` ✓ Fi.CI.IGT: " Patchwork

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=c9876362-5377-f73b-16ca-0de5122e7983@intel.com \
    --to=shashank.sharma@intel.com \
    --cc=animesh.manna@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=michel.thierry@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox