On Thu, Dec 26, 2019 at 12:55 AM Sasha Levin <sashal(a)kernel.org> wrote:
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.4.5, v5.3.18, v4.19.90, v4.14.159, v4.9.206, v4.4.206.
>
> v5.4.5: Build OK!
> v5.3.18: Build OK!
> v4.19.90: Build OK!
> v4.14.159: Failed to apply! Possible dependencies:
> 6dd0394f5fcd ("media: v4l2-compat-ioctl32: better name userspace pointers")
> fef6cc6b3618 ("media: v4l2-compat-ioctl32: fix several __user annotations")
>
> v4.9.206: Failed to apply! Possible dependencies:
> 6dd0394f5fcd ("media: v4l2-compat-ioctl32: better name userspace pointers")
> a56bc171598c ("[media] v4l: compat: Prevent allocating excessive amounts of memory")
> ba7ed691dcce ("[media] v4l2-compat-ioctl32: VIDIOC_S_EDID should return all fields on error")
> fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format")
> fef6cc6b3618 ("media: v4l2-compat-ioctl32: fix several __user annotations")
>
> v4.4.206: Failed to apply! Possible dependencies:
> 0579e6e3a326 ("doc-rst: linux_tv: remove whitespaces")
> 17defc282fe6 ("Documentation: add meta-documentation for Sphinx and kernel-doc")
> 22cba31bae9d ("Documentation/sphinx: add basic working Sphinx configuration and build")
> 234d549662a7 ("doc-rst: video: use reference for VIDIOC_ENUMINPUT")
> 5377d91f3e88 ("doc-rst: linux_tv DocBook to reST migration (docs-next)")
> 6dd0394f5fcd ("media: v4l2-compat-ioctl32: better name userspace pointers")
> 7347081e8a52 ("doc-rst: linux_tv: simplify references")
> 789818845202 ("doc-rst: audio: Fix some cross references")
> 94fff0dc5333 ("doc-rst: dmx_fcalls: improve man-like format")
> 9e00ffca8cc7 ("doc-rst: querycap: fix troubles on some references")
> af4a4d0db8ab ("doc-rst: linux_tv: Replace reference names to match ioctls")
> c2b66cafdf02 ("[media] v4l: doc: Remove row numbers from tables")
> e6702ee18e24 ("doc-rst: app-pri: Fix a bad reference")
> fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
I think we need it to support users of musl on old kernels: musl is
adding conversion functions for emulating the new (time64) ioctl
commands on top of the old format, and without my patch, the
new commands do not necessarily return an error that musl can
catch.
I can provide a backport of my patch to v4.4 and v4.9 for this when
the patch has made it into mainline. Can you notify me again when
the time has come?
A related question that we should address is whether we want the v4l2
and alsa time64 ioctl patches backported as well, and to which kernels
(if any).
My feeling is that we don't want them those in v4.14 and earlier because
that is rather pointless with musl already having emulation in user space
and the rest of the kernel not being y2038 safe at all.
For v5.4 I'd say we do want them, and possibly all the other remaining
y2038 patches as well, I have a tree[1] that I try to keep up to date
with the versions that got posted and/or merged, as I know there is
demand for it. If you prefer not to have them in v5.4.y, I can keep them
here myself and make sure it's possible to my branch into that instead.
v4.19 is a bit borderline: if we decide to do the backports to v5.4 and
there is demand for v4.19.y, I could also try to pick the most important
patches from my tree and backport them to v4.19.0 (including a lot of
work that went into v5.1) and then look at that tree to see if it should
be part of the official v4.19.y or not.
Arnd
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=…
In order to avoid confusing the HW, we must never submit an empty ring
during lite-restore, that is we should always advance the RING_TAIL
before submitting to stay ahead of the RING_HEAD.
Normally this is prevented by keeping a couple of spare NOPs in the
request->wa_tail so that on resubmission we can advance the tail. This
relies on the request only being resubmitted once, which is the normal
condition as it is seen once for ELSP[1] and then later in ELSP[0]. On
preemption, the requests are unwound and the tail reset back to the
normal end point (as we know the request is incomplete and therefore its
RING_HEAD is even earlier).
However, if this w/a should fail we would try and resubmit the request
with the RING_TAIL already set to the location of this request's wa_tail
potentially causing a GPU hang. We can spot when we do try and
incorrectly resubmit without advancing the RING_TAIL and spare any
embarrassment by forcing the context restore.
In the case of preempt-to-busy, we leave the requests running on the HW
while we unwind. As the ring is still live, we cannot rewind our
rq->tail without forcing a reload so leave it set to rq->wa_tail and
only force a reload if we resubmit after a lite-restore. (Normally, the
forced reload will be a part of the preemption event.)
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/673
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
Cc: stable(a)vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20191209023215.3519970-1-chri…
(cherry picked from commit 82c69bf58650e644c61aa2bf5100b63a1070fd2f)
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 42 ++++++++++++++---------------
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 06a506c29463..6600b2e08fe3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -471,12 +471,6 @@ lrc_descriptor(struct intel_context *ce, struct intel_engine_cs *engine)
return desc;
}
-static void unwind_wa_tail(struct i915_request *rq)
-{
- rq->tail = intel_ring_wrap(rq->ring, rq->wa_tail - WA_TAIL_BYTES);
- assert_ring_tail_valid(rq->ring, rq->tail);
-}
-
static struct i915_request *
__unwind_incomplete_requests(struct intel_engine_cs *engine)
{
@@ -495,7 +489,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
continue; /* XXX */
__i915_request_unsubmit(rq);
- unwind_wa_tail(rq);
/*
* Push the request back into the queue for later resubmission.
@@ -649,13 +642,29 @@ execlists_schedule_out(struct i915_request *rq)
i915_request_put(rq);
}
-static u64 execlists_update_context(const struct i915_request *rq)
+static u64 execlists_update_context(struct i915_request *rq)
{
struct intel_context *ce = rq->hw_context;
- u64 desc;
+ u64 desc = ce->lrc_desc;
+ u32 tail;
- ce->lrc_reg_state[CTX_RING_TAIL + 1] =
- intel_ring_set_tail(rq->ring, rq->tail);
+ /*
+ * WaIdleLiteRestore:bdw,skl
+ *
+ * We should never submit the context with the same RING_TAIL twice
+ * just in case we submit an empty ring, which confuses the HW.
+ *
+ * We append a couple of NOOPs (gen8_emit_wa_tail) after the end of
+ * the normal request to be able to always advance the RING_TAIL on
+ * subsequent resubmissions (for lite restore). Should that fail us,
+ * and we try and submit the same tail again, force the context
+ * reload.
+ */
+ tail = intel_ring_set_tail(rq->ring, rq->tail);
+ if (unlikely(ce->lrc_reg_state[CTX_RING_TAIL + 1] == tail))
+ desc |= CTX_DESC_FORCE_RESTORE;
+ ce->lrc_reg_state[CTX_RING_TAIL + 1] = tail;
+ rq->tail = rq->wa_tail;
/*
* Make sure the context image is complete before we submit it to HW.
@@ -674,7 +683,6 @@ static u64 execlists_update_context(const struct i915_request *rq)
*/
mb();
- desc = ce->lrc_desc;
ce->lrc_desc &= ~CTX_DESC_FORCE_RESTORE;
return desc;
@@ -1149,16 +1157,6 @@ static void execlists_dequeue(struct intel_engine_cs *engine)
if (!list_is_last(&last->sched.link,
&engine->active.requests))
return;
-
- /*
- * WaIdleLiteRestore:bdw,skl
- * Apply the wa NOOPs to prevent
- * ring:HEAD == rq:TAIL as we resubmit the
- * request. See gen8_emit_fini_breadcrumb() for
- * where we prepare the padding after the
- * end of the request.
- */
- last->tail = last->wa_tail;
}
}
--
2.25.0.rc0
link_startup_again flow in ufshcd_link_startup() is not necessary
since currently device can be moved to "active" power mode during
resume flow by commit as below,
"scsi: ufs: set device as default active power mode during
initialization only"
Fixes: 7caf489b99a4 (scsi: ufs: issue link starup 2 times if device isn't active)
Cc: Alim Akhtar <alim.akhtar(a)samsung.com>
Cc: Avri Altman <avri.altman(a)wdc.com>
Cc: Bart Van Assche <bvanassche(a)acm.org>
Cc: Bean Huo <beanhuo(a)micron.com>
Cc: Can Guo <cang(a)codeaurora.org>
Cc: Matthias Brugger <matthias.bgg(a)gmail.com>
Cc: Subhash Jadavani <subhashj(a)codeaurora.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Stanley Chu <stanley.chu(a)mediatek.com>
---
drivers/scsi/ufs/ufshcd.c | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 9abb7085a5d0..1900f811394a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4365,16 +4365,7 @@ static int ufshcd_link_startup(struct ufs_hba *hba)
{
int ret;
int retries = DME_LINKSTARTUP_RETRIES;
- bool link_startup_again = false;
- /*
- * If UFS device isn't active then we will have to issue link startup
- * 2 times to make sure the device state move to active.
- */
- if (!ufshcd_is_ufs_dev_active(hba))
- link_startup_again = true;
-
-link_startup:
do {
ufshcd_vops_link_startup_notify(hba, PRE_CHANGE);
@@ -4408,12 +4399,6 @@ static int ufshcd_link_startup(struct ufs_hba *hba)
goto out;
}
- if (link_startup_again) {
- link_startup_again = false;
- retries = DME_LINKSTARTUP_RETRIES;
- goto link_startup;
- }
-
/* Mark that link is up in PWM-G1, 1-lane, SLOW-AUTO mode */
ufshcd_init_pwr_info(hba);
ufshcd_print_pwr_info(hba);
--
2.18.0