From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>,
Mikko Perttunen <cyndis@kapsi.fi>
Cc: linux-tegra@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 1/3] gpu: host1x: Cancel only job that actually got stuck
Date: Tue, 7 Aug 2018 16:07:11 +0300 [thread overview]
Message-ID: <20180807130713.1016-2-digetx@gmail.com> (raw)
In-Reply-To: <20180807130713.1016-1-digetx@gmail.com>
Host1x doesn't have information about jobs inter-dependency, that is
something that will become available once host1x will get a proper
jobs scheduler implementation. Currently a hang job causes other unrelated
jobs to be canceled, that is a relic from downstream driver which is
irrelevant to upstream. Let's cancel only the hanging job and not to touch
other jobs in queue.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/gpu/host1x/cdma.c | 33 +++++++--------------------------
1 file changed, 7 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 91df51e631b2..75f339f5df6f 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -348,13 +348,11 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma *cdma,
}
/*
- * Walk the sync_queue, first incrementing with the CPU syncpts that
- * are partially executed (the first buffer) or fully skipped while
- * still in the current context (slots are also NOP-ed).
+ * Increment with CPU the remaining syncpts of a partially executed job.
*
- * At the point contexts are interleaved, syncpt increments must be
- * done inline with the pushbuffer from a GATHER buffer to maintain
- * the order (slots are modified to be a GATHER of syncpt incrs).
+ * Syncpt increments must be done inline with the pushbuffer from a
+ * GATHER buffer to maintain the order (slots are modified to be a
+ * GATHER of syncpt incrs).
*
* Note: save in restart_addr the location where the timed out buffer
* started in the PB, so we can start the refetch from there (with the
@@ -362,20 +360,15 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma *cdma,
* properly for this buffer and resources are freed.
*/
- dev_dbg(dev, "%s: perform CPU incr on pending same ctx buffers\n",
- __func__);
+ dev_dbg(dev, "%s: perform CPU incr on pending buffers\n", __func__);
if (!list_empty(&cdma->sync_queue))
restart_addr = job->first_get;
else
restart_addr = cdma->last_pos;
- /* do CPU increments as long as this context continues */
- list_for_each_entry_from(job, &cdma->sync_queue, list) {
- /* different context, gets us out of this loop */
- if (job->client != cdma->timeout.client)
- break;
-
+ /* do CPU increments for the remaining syncpts */
+ if (job) {
/* won't need a timeout when replayed */
job->timeout = 0;
@@ -388,20 +381,8 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma *cdma,
host1x_hw_cdma_timeout_cpu_incr(host1x, cdma, job->first_get,
syncpt_incrs, job->syncpt_end,
job->num_slots);
-
- syncpt_val += syncpt_incrs;
}
- /*
- * The following sumbits from the same client may be dependent on the
- * failed submit and therefore they may fail. Force a small timeout
- * to make the queue cleanup faster.
- */
-
- list_for_each_entry_from(job, &cdma->sync_queue, list)
- if (job->client == cdma->timeout.client)
- job->timeout = min_t(unsigned int, job->timeout, 500);
-
dev_dbg(dev, "%s: finished sync_queue modification\n", __func__);
/* roll back DMAGET and start up channel again */
--
2.18.0
next prev parent reply other threads:[~2018-08-07 13:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-07 13:07 [PATCH v2 0/3] host1x_cdma_update_sync_queue() clean up Dmitry Osipenko
2018-08-07 13:07 ` Dmitry Osipenko [this message]
2018-08-07 13:07 ` [PATCH v2 2/3] gpu: host1x: Don't complete a completed job Dmitry Osipenko
2018-10-09 5:00 ` Mikko Perttunen
2018-08-07 13:07 ` [PATCH v2 3/3] gpu: host1x: Continue CDMA execution starting with a next job Dmitry Osipenko
2018-08-18 15:10 ` Dmitry Osipenko
2018-10-09 5:10 ` Mikko Perttunen
2018-10-09 5:10 ` Mikko Perttunen
2018-10-09 9:16 ` Dmitry Osipenko
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=20180807130713.1016-2-digetx@gmail.com \
--to=digetx@gmail.com \
--cc=cyndis@kapsi.fi \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=thierry.reding@gmail.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.