All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: Boris Brezillon <boris.brezillon@collabora.com>,
	dri-devel@lists.freedesktop.org
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Rob Herring <robh+dt@kernel.org>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v4 09/14] drm/panfrost: Make sure job interrupts are masked before resetting
Date: Mon, 28 Jun 2021 10:47:53 +0100	[thread overview]
Message-ID: <c7bf8235-3b8c-fbec-42bc-1f7f3fa80c77@arm.com> (raw)
In-Reply-To: <20210628074210.2695399-10-boris.brezillon@collabora.com>

On 28/06/2021 08:42, Boris Brezillon wrote:
> This is not yet needed because we let active jobs be killed during by
> the reset and we don't really bother making sure they can be restarted.
> But once we start adding soft-stop support, controlling when we deal
> with the remaining interrrupts and making sure those are handled before
> the reset is issued gets tricky if we keep job interrupts active.
> 
> Let's prepare for that and mask+flush job IRQs before issuing a reset.
> 
> v4:
> * Add a comment explaining why we WARN_ON(!job) in the irq handler
> * Keep taking the job_lock when evicting stalled jobs
> 
> v3:
> * New patch
> 
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>

Reviewed-by: Steven Price <steven.price@arm.com>

> ---
>  drivers/gpu/drm/panfrost/panfrost_job.c | 27 ++++++++++++++++++++-----
>  1 file changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c
> index 98193a557a2d..4bd4d11377b7 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -34,6 +34,7 @@ struct panfrost_queue_state {
>  struct panfrost_job_slot {
>  	struct panfrost_queue_state queue[NUM_JOB_SLOTS];
>  	spinlock_t job_lock;
> +	int irq;
>  };
>  
>  static struct panfrost_job *
> @@ -400,6 +401,15 @@ static void panfrost_reset(struct panfrost_device *pfdev,
>  	if (bad)
>  		drm_sched_increase_karma(bad);
>  
> +	/* Mask job interrupts and synchronize to make sure we won't be
> +	 * interrupted during our reset.
> +	 */
> +	job_write(pfdev, JOB_INT_MASK, 0);
> +	synchronize_irq(pfdev->js->irq);
> +
> +	/* Schedulers are stopped and interrupts are masked+flushed, we don't
> +	 * need to protect the 'evict unfinished jobs' lock with the job_lock.
> +	 */
>  	spin_lock(&pfdev->js->job_lock);
>  	for (i = 0; i < NUM_JOB_SLOTS; i++) {
>  		if (pfdev->jobs[i]) {
> @@ -502,7 +512,14 @@ static void panfrost_job_handle_irq(struct panfrost_device *pfdev, u32 status)
>  			struct panfrost_job *job;
>  
>  			job = pfdev->jobs[j];
> -			/* Only NULL if job timeout occurred */
> +			/* The only reason this job could be NULL is if the
> +			 * job IRQ handler is called just after the
> +			 * in-flight job eviction in the reset path, and
> +			 * this shouldn't happen because the job IRQ has
> +			 * been masked and synchronized when this eviction
> +			 * happens.
> +			 */
> +			WARN_ON(!job);
>  			if (job) {
>  				pfdev->jobs[j] = NULL;
>  
> @@ -562,7 +579,7 @@ static void panfrost_reset_work(struct work_struct *work)
>  int panfrost_job_init(struct panfrost_device *pfdev)
>  {
>  	struct panfrost_job_slot *js;
> -	int ret, j, irq;
> +	int ret, j;
>  
>  	INIT_WORK(&pfdev->reset.work, panfrost_reset_work);
>  
> @@ -572,11 +589,11 @@ int panfrost_job_init(struct panfrost_device *pfdev)
>  
>  	spin_lock_init(&js->job_lock);
>  
> -	irq = platform_get_irq_byname(to_platform_device(pfdev->dev), "job");
> -	if (irq <= 0)
> +	js->irq = platform_get_irq_byname(to_platform_device(pfdev->dev), "job");
> +	if (js->irq <= 0)
>  		return -ENODEV;
>  
> -	ret = devm_request_threaded_irq(pfdev->dev, irq,
> +	ret = devm_request_threaded_irq(pfdev->dev, js->irq,
>  					panfrost_job_irq_handler,
>  					panfrost_job_irq_handler_thread,
>  					IRQF_SHARED, KBUILD_MODNAME "-job",
> 


  reply	other threads:[~2021-06-28  9:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28  7:41 [PATCH v4 00/14] drm/panfrost: Misc improvements Boris Brezillon
2021-06-28  7:41 ` [PATCH v4 01/14] drm/sched: Allow using a dedicated workqueue for the timeout/fault tdr Boris Brezillon
2021-06-28  9:23   ` Steven Price
2021-06-28  9:57   ` Lucas Stach
2021-06-28  7:41 ` [PATCH v4 02/14] drm/panfrost: Make ->run_job() return an ERR_PTR() when appropriate Boris Brezillon
2021-06-28  7:41 ` [PATCH v4 03/14] drm/panfrost: Get rid of the unused JS_STATUS_EVENT_ACTIVE definition Boris Brezillon
2021-06-28  7:42 ` [PATCH v4 04/14] drm/panfrost: Drop the pfdev argument passed to panfrost_exception_name() Boris Brezillon
2021-06-28  7:42 ` [PATCH v4 05/14] drm/panfrost: Do the exception -> string translation using a table Boris Brezillon
2021-06-28  7:42 ` [PATCH v4 06/14] drm/panfrost: Expose a helper to trigger a GPU reset Boris Brezillon
2021-06-28  7:42 ` [PATCH v4 07/14] drm/panfrost: Use a threaded IRQ for job interrupts Boris Brezillon
2021-06-28  9:26   ` Steven Price
2021-06-28  9:39     ` Boris Brezillon
2021-06-28  7:42 ` [PATCH v4 08/14] drm/panfrost: Simplify the reset serialization logic Boris Brezillon
2021-06-28  9:45   ` Steven Price
2021-06-28  7:42 ` [PATCH v4 09/14] drm/panfrost: Make sure job interrupts are masked before resetting Boris Brezillon
2021-06-28  9:47   ` Steven Price [this message]
2021-06-28  7:42 ` [PATCH v4 10/14] drm/panfrost: Disable the AS on unhandled page faults Boris Brezillon
2021-06-28  7:42 ` [PATCH v4 11/14] drm/panfrost: Reset the GPU when the AS_ACTIVE bit is stuck Boris Brezillon
2021-06-28  7:42 ` [PATCH v4 12/14] drm/panfrost: Don't reset the GPU on job faults unless we really have to Boris Brezillon
2021-06-28  9:49   ` Steven Price
2021-06-28  7:42 ` [PATCH v4 13/14] drm/panfrost: Kill in-flight jobs on FD close Boris Brezillon
2021-06-28 10:04   ` Steven Price
2021-06-28  7:42 ` [PATCH v4 14/14] drm/panfrost: Queue jobs on the hardware Boris Brezillon
2021-06-28 13:35   ` Steven Price

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=c7bf8235-3b8c-fbec-42bc-1f7f3fa80c77@arm.com \
    --to=steven.price@arm.com \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=boris.brezillon@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=tomeu.vizoso@collabora.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.