Re: [Intel-gfx] [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value
Hi, On 7/7/20 9:34 AM, Uwe Kleine-König wrote: On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: Hi, Thank you for your review and sorry for the slow reply. No problem for me, I didn't hold my breath :-) diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c index 43b1fc634af1..80d0f9c64f9d 100644 --- a/drivers/pwm/pwm-lpss.c +++ b/drivers/pwm/pwm-lpss.c @@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm, freq *= base_unit_range; base_unit = DIV_ROUND_CLOSEST_ULL(freq, c); DIV_ROUND_CLOSEST_ULL is most probably wrong, too. But I didn't spend the time to actually confirm that. Yes I saw your comment elsewhere that the PWM API defines rounding in a certain direction, but fixing that falls outside of this patch. Yeah, sure. [...] I hope this helps to explain what is going on a bit. I will try to make sense of that and reply to the patch directly when I succeeded. In case it helps here is the datasheet for the LPSS PWM controller (somewhat hard to find if you don't know what you are looking for): https://cdrdv2.intel.com/v1/dl/getcontent/332065 https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-2.pdf The first link contains a description about how the PWM controller works in section 17.5 "SIO - Pulse Width Modulation (PWM)", the second link contains all register definitions for the SoC and is not all that interesting other then for verifying the existing register bits defines. Regards, Hans ### As for the behavior on base_unit==0 in the get_state method, as mentioned above I wrote that when I did not fully understood how the controller works. We really should never encounter this. But if we do then I think closest to the truth would be: state->period = UINT_MAX; state->duty_cycle = 0; I'd say state->period = 1 & state->duty_cycle = 0 is a better representation. Best regards Uwe ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DG1 VRAM question
On 01/07/2020 00:27, Dave Airlie wrote:
On Sat, 27 Jun 2020 at 03:17, Daniele Ceraolo Spurio
wrote:
On 6/26/20 12:14 AM, Lucas De Marchi wrote:
Cc Matt and Daniele
On Thu, Jun 25, 2020 at 9:38 PM Dave Airlie wrote:
I can't figure this out easily so I'd thought I'd just ask, but does
DG1 have VRAM > PCIE aperture, I'm not sure I've see any mention of
We'd need to go via lmem since there's no mappable aperture. There are
a few patches in tree for that
(see e.g. 54b512cd7a6d ("drm/i915: do not map aperture if it is not
available.")) but more missing.
To clarify, although the legacy aperture mapping that allowed the CPU to
access memory via the GGTT for swizzling is gone, VRAM/LMEM is still
cpu-mappable via pci bar.
Will leave the questions about possible trashing to Matt as he's more
familiar than me with how this works.
Matt?
Is DG1 assuming we can get 64-bit BARs always and the CPU will have
access to the complete VRAM? or is there any ideas about what happens
in those situations where 64-bit BARs aren't available and there is
memory pressure on the PCI BAR space.
With other discrete GPUs we've got lots of things like visible VRAM
limitations, writing page tables with GPU hw instead of from the CPU,
having mapping bring things into the visible area, so you can stream
something into VRAM, but then it'll migrated to non-visible area if
it's unmapped and there is memory pressure.
Yes, we just assume that LMEM size == LMEMBAR size, where the whole
thing is 1:1 mapped and CPU visible. We don't currently have the concept
of CPU visible/non-visible LMEM.
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update dma-attributes for our sg DMA
On 06/07/2020 23:43, Chris Wilson wrote: Looking through the attributes for DMA mappings, it appears that by default dma_map_sg will try and create a kernel accessible map of the page. We never access this, as we either have a struct page already or an iomap, so we can request that the dma mapper does not create one. Without a kernel map in place, one presumes the rest of the memory control attributes do not apply. We also explicitly control the caches around the mappings, so we can ask it not to bother synchronising itself. Signed-off-by: Chris Wilson Cc: Matthew Auld Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Pin the rings before marking active
On Mon, 6 Jul 2020 at 18:01, Chris Wilson wrote:
>
> On eviction, we acquire the vm->mutex and then wait on the vma->active.
> Thereore when binding and pinning the vma, we must follow the same
> sequence, lock/pin the vma then mark it active. Otherwise, we mark the
> vma as active, then wait for the vm->mutex, and meanwhile the evictor
> holding the mutex waits upon us to complete our activity.
>
> Fixes: 8ccfc20a7d56 ("drm/i915/gt: Mark ring->vma as active while pinned")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: # v5.6+
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/23] drm/i915: Dirty hack to fix selftests locking inversion
Op 03-07-2020 om 15:48 schreef Tvrtko Ursulin: > > On 03/07/2020 13:22, Maarten Lankhorst wrote: >> Some i915 selftests still use i915_vma_lock() as inner lock, and >> intel_context_create_request() intel_timeline->mutex as outer lock. >> Fortunately for selftests this is not an issue, they should be fixed >> but we can move ahead and cleanify lockdep now. > > Mentions and existence of "dirty hacks" will hopefully be removed from the > series before it can be considered merge ready? > > Regards, > > Tvrtko > >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/i915/gt/intel_context.c | 12 >> 1 file changed, 12 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c >> b/drivers/gpu/drm/i915/gt/intel_context.c >> index 64948386630f..fe9fff5a63b1 100644 >> --- a/drivers/gpu/drm/i915/gt/intel_context.c >> +++ b/drivers/gpu/drm/i915/gt/intel_context.c >> @@ -459,6 +459,18 @@ struct i915_request >> *intel_context_create_request(struct intel_context *ce) >> rq = i915_request_create(ce); >> intel_context_unpin(ce); >> + if (IS_ERR(rq)) >> + return rq; >> + >> + /* >> + * timeline->mutex should be the inner lock, but is used as outer lock. >> + * Hack around this to shut up lockdep in selftests.. >> + */ >> + lockdep_unpin_lock(&ce->timeline->mutex, rq->cookie); >> + mutex_release(&ce->timeline->mutex.dep_map, _RET_IP_); >> + mutex_acquire(&ce->timeline->mutex.dep_map, SINGLE_DEPTH_NESTING, 0, >> _RET_IP_); >> + rq->cookie = lockdep_pin_lock(&ce->timeline->mutex); >> + >> return rq; >> } >> Hey, We're trying to invert the locking order with vma lock vs request lock, while this is a hack, it will not affect normal running code, it's only meant to shut up lockdep in the selftests. This is mainly so we can fix the selftests one by one, without breaking the world. Ideally when mm.obj lands, we already corrected the lock ordering. We may keep this macro for selftests, but until lock reordering in selftests is complete we will need this temporarily. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/12] drm/i915/gt: Drop atomic for engine->fw_active tracking
Since schedule-in/out is now entirely serialised by the tasklet bitlock,
we do not need to worry about concurrent in/out operations and so reduce
the atomic operations to plain instructions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index b024ac1debc7..d58e5e251ff3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1540,7 +1540,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
ktime_to_ms(intel_engine_get_busy_time(engine,
&dummy)));
drm_printf(m, "\tForcewake: %x domains, %d active\n",
- engine->fw_domain, atomic_read(&engine->fw_active));
+ engine->fw_domain, READ_ONCE(engine->fw_active));
rcu_read_lock();
rq = READ_ONCE(engine->heartbeat.systole);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 490af81bd6f3..b8d8973e6f97 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -322,7 +322,7 @@ struct intel_engine_cs {
* as possible.
*/
enum forcewake_domains fw_domain;
- atomic_t fw_active;
+ unsigned int fw_active;
unsigned long context_tag;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ab57e9329bc1..d9054fae8925 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1350,7 +1350,7 @@ __execlists_schedule_in(struct i915_request *rq)
ce->lrc.ccid |= engine->execlists.ccid;
__intel_gt_pm_get(engine->gt);
- if (engine->fw_domain && !atomic_fetch_inc(&engine->fw_active))
+ if (engine->fw_domain && !engine->fw_active++)
intel_uncore_forcewake_get(engine->uncore, engine->fw_domain);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
intel_engine_context_in(engine);
@@ -1455,7 +1455,7 @@ static inline void __execlists_schedule_out(struct
i915_request *rq)
intel_context_update_runtime(ce);
intel_engine_context_out(engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
- if (engine->fw_domain && !atomic_dec_return(&engine->fw_active))
+ if (engine->fw_domain && !--engine->fw_active)
intel_uncore_forcewake_put(engine->uncore, engine->fw_domain);
intel_gt_pm_put_async(engine->gt);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Reduce interrupts-off time for execlists submission
Since we started doing direct submission to reduce the initial submission stall, we split the submit tasklet into two: one part that was wholly undercontrol of the tasklet, and the rest called from mixed contexts. For the latter, we required additional extra spinlocks and atomic handling to ensure concurrent operations, and worse, required those sequences to use irq-off. Instead of calling individual components of the submission process, we can just call the whole tasklet and so replace the individual locking with a known serialised calling context. That turns out to be far simpler, and reduces the irqoff time required for the tasklet, improving the parallelism of the hw. Slightly better latency, slightly higher throughput, and slightly lower impact on system latency. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/12] drm/i915/gt: Defer schedule_out until after the dequeue
Inside schedule_out, we do extra work upon idling the context, such as
updating the runtime, kicking off retires, kicking virtual engines.
However, if we are in a series of processing single requests per
contexts, we may find ourselves scheduling out the context, only to
immediately schedule it back in during dequeue. This is just extra work
that we can avoid if we keep the context marked as inflight across the
dequeue. This becomes more significant later on for minimising virtual
engine misses.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 111 --
2 files changed, 78 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 4954b0df4864..b63db45bab7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -45,8 +45,8 @@ struct intel_context {
struct intel_engine_cs *engine;
struct intel_engine_cs *inflight;
-#define intel_context_inflight(ce) ptr_mask_bits(READ_ONCE((ce)->inflight), 2)
-#define intel_context_inflight_count(ce)
ptr_unmask_bits(READ_ONCE((ce)->inflight), 2)
+#define intel_context_inflight(ce) ptr_mask_bits(READ_ONCE((ce)->inflight), 3)
+#define intel_context_inflight_count(ce)
ptr_unmask_bits(READ_ONCE((ce)->inflight), 3)
struct i915_address_space *vm;
struct i915_gem_context __rcu *gem_context;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e7eec78a2e55..1f4483c0bbdd 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1385,6 +1385,8 @@ __execlists_schedule_in(struct i915_request *rq)
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
intel_engine_context_in(engine);
+ CE_TRACE(ce, "schedule-in, ccid:%x\n", ce->lrc.ccid);
+
return engine;
}
@@ -1428,6 +1430,8 @@ __execlists_schedule_out(struct i915_request *rq,
* refrain from doing non-trivial work here.
*/
+ CE_TRACE(ce, "schedule-out, ccid:%x\n", ccid);
+
/*
* If we have just completed this context, the engine may now be
* idle and we want to re-enter powersaving.
@@ -2075,11 +2079,6 @@ static void set_preempt_timeout(struct intel_engine_cs
*engine,
active_preempt_timeout(engine, rq));
}
-static inline void clear_ports(struct i915_request **ports, int count)
-{
- memset_p((void **)ports, NULL, count);
-}
-
static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -2430,26 +2429,36 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
start_timeslice(engine, execlists->queue_priority_hint);
skip_submit:
ring_set_paused(engine, 0);
+ while (port-- != execlists->pending)
+ i915_request_put(*port);
*execlists->pending = NULL;
}
}
-static void
-cancel_port_requests(struct intel_engine_execlists * const execlists)
+static inline void clear_ports(struct i915_request **ports, int count)
+{
+ memset_p((void **)ports, NULL, count);
+}
+
+static struct i915_request **
+cancel_port_requests(struct intel_engine_execlists * const execlists,
+struct i915_request **inactive)
{
struct i915_request * const *port;
for (port = execlists->pending; *port; port++)
- execlists_schedule_out(*port);
+ *inactive++ = *port;
clear_ports(execlists->pending, ARRAY_SIZE(execlists->pending));
/* Mark the end of active before we overwrite *active */
for (port = xchg(&execlists->active, execlists->pending); *port; port++)
- execlists_schedule_out(*port);
+ *inactive++ = *port;
clear_ports(execlists->inflight, ARRAY_SIZE(execlists->inflight));
smp_wmb(); /* complete the seqlock for execlists_active() */
WRITE_ONCE(execlists->active, execlists->inflight);
+
+ return inactive;
}
static inline void
@@ -2521,7 +2530,8 @@ gen8_csb_parse(const struct intel_engine_execlists
*execlists, const u32 *csb)
return *csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
}
-static void process_csb(struct intel_engine_cs *engine)
+static struct i915_request **
+process_csb(struct intel_engine_cs *engine, struct i915_request **inactive)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
const u32 * const buf = execlists->csb_status;
@@ -2550,7 +2560,7 @@ static void process_csb(struct intel_engine_cs *engine)
head = execlists->csb_head;
tail = READ_ONCE(*execlists->csb_write);
if (unlikely(head == tail))
- return;
+ return
[Intel-gfx] [PATCH 12/12] drm/i915/gt: Convert stats.active to plain unsigned int
As context-in/out is now always serialised, we do not have to worry
about concurrent enabling/disable of the busy-stats and can reduce the
atomic_t active to a plain unsigned int, and the seqlock to a seqcount.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 8 ++--
drivers/gpu/drm/i915/gt/intel_engine_stats.h | 45
drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 +-
3 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index d58e5e251ff3..06a65b280111 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -338,7 +338,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
engine->schedule = NULL;
ewma__engine_latency_init(&engine->latency);
- seqlock_init(&engine->stats.lock);
+ seqcount_init(&engine->stats.lock);
ATOMIC_INIT_NOTIFIER_HEAD(&engine->context_status_notifier);
@@ -1617,7 +1617,7 @@ static ktime_t __intel_engine_get_busy_time(struct
intel_engine_cs *engine,
* add it to the total.
*/
*now = ktime_get();
- if (atomic_read(&engine->stats.active))
+ if (READ_ONCE(engine->stats.active))
total = ktime_add(total, ktime_sub(*now, engine->stats.start));
return total;
@@ -1636,9 +1636,9 @@ ktime_t intel_engine_get_busy_time(struct intel_engine_cs
*engine, ktime_t *now)
ktime_t total;
do {
- seq = read_seqbegin(&engine->stats.lock);
+ seq = read_seqcount_begin(&engine->stats.lock);
total = __intel_engine_get_busy_time(engine, now);
- } while (read_seqretry(&engine->stats.lock, seq));
+ } while (read_seqcount_retry(&engine->stats.lock, seq));
return total;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_stats.h
b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
index 58491eae3482..24fbdd94351a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_stats.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
@@ -17,33 +17,44 @@ static inline void intel_engine_context_in(struct
intel_engine_cs *engine)
{
unsigned long flags;
- if (atomic_add_unless(&engine->stats.active, 1, 0))
+ if (engine->stats.active) {
+ engine->stats.active++;
return;
-
- write_seqlock_irqsave(&engine->stats.lock, flags);
- if (!atomic_add_unless(&engine->stats.active, 1, 0)) {
- engine->stats.start = ktime_get();
- atomic_inc(&engine->stats.active);
}
- write_sequnlock_irqrestore(&engine->stats.lock, flags);
+
+ /* The writer is serialised; but the pmu reader may be from hardirq */
+ local_irq_save(flags);
+ write_seqcount_begin(&engine->stats.lock);
+
+ engine->stats.start = ktime_get();
+ engine->stats.active++;
+
+ write_seqcount_end(&engine->stats.lock);
+ local_irq_restore(flags);
+
+ GEM_BUG_ON(!engine->stats.active);
}
static inline void intel_engine_context_out(struct intel_engine_cs *engine)
{
unsigned long flags;
- GEM_BUG_ON(!atomic_read(&engine->stats.active));
-
- if (atomic_add_unless(&engine->stats.active, -1, 1))
+ GEM_BUG_ON(!engine->stats.active);
+ if (engine->stats.active > 1) {
+ engine->stats.active--;
return;
-
- write_seqlock_irqsave(&engine->stats.lock, flags);
- if (atomic_dec_and_test(&engine->stats.active)) {
- engine->stats.total =
- ktime_add(engine->stats.total,
- ktime_sub(ktime_get(), engine->stats.start));
}
- write_sequnlock_irqrestore(&engine->stats.lock, flags);
+
+ local_irq_save(flags);
+ write_seqcount_begin(&engine->stats.lock);
+
+ engine->stats.active--;
+ engine->stats.total =
+ ktime_add(engine->stats.total,
+ ktime_sub(ktime_get(), engine->stats.start));
+
+ write_seqcount_end(&engine->stats.lock);
+ local_irq_restore(flags);
}
#endif /* __INTEL_ENGINE_STATS_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index b8d8973e6f97..242b6bbd7fe3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -545,12 +545,12 @@ struct intel_engine_cs {
/**
* @active: Number of contexts currently scheduled in.
*/
- atomic_t active;
+ unsigned int active;
/**
* @lock: Lock protecting the below fields.
*/
- seqlock_t lock;
+ seqcount_t lock;
/**
* @total: Total time this engine was busy.
--
2.20.1
[Intel-gfx] [PATCH 11/12] drm/i915/gt: Extract busy-stats for ring-scheduler
Lift the busy-stats context-in/out implementation out of intel_lrc, so
that we can reuse it for other scheduler implementations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_stats.h | 49
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 +-
2 files changed, 50 insertions(+), 33 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_stats.h
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_stats.h
b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
new file mode 100644
index ..58491eae3482
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#ifndef __INTEL_ENGINE_STATS_H__
+#define __INTEL_ENGINE_STATS_H__
+
+#include
+#include
+#include
+
+#include "i915_gem.h" /* GEM_BUG_ON */
+#include "intel_engine.h"
+
+static inline void intel_engine_context_in(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+
+ if (atomic_add_unless(&engine->stats.active, 1, 0))
+ return;
+
+ write_seqlock_irqsave(&engine->stats.lock, flags);
+ if (!atomic_add_unless(&engine->stats.active, 1, 0)) {
+ engine->stats.start = ktime_get();
+ atomic_inc(&engine->stats.active);
+ }
+ write_sequnlock_irqrestore(&engine->stats.lock, flags);
+}
+
+static inline void intel_engine_context_out(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+
+ GEM_BUG_ON(!atomic_read(&engine->stats.active));
+
+ if (atomic_add_unless(&engine->stats.active, -1, 1))
+ return;
+
+ write_seqlock_irqsave(&engine->stats.lock, flags);
+ if (atomic_dec_and_test(&engine->stats.active)) {
+ engine->stats.total =
+ ktime_add(engine->stats.total,
+ ktime_sub(ktime_get(), engine->stats.start));
+ }
+ write_sequnlock_irqrestore(&engine->stats.lock, flags);
+}
+
+#endif /* __INTEL_ENGINE_STATS_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d9054fae8925..6e23e3063b81 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -139,6 +139,7 @@
#include "i915_vgpu.h"
#include "intel_context.h"
#include "intel_engine_pm.h"
+#include "intel_engine_stats.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -1164,39 +1165,6 @@ execlists_context_status_change(struct i915_request *rq,
unsigned long status)
status, rq);
}
-static void intel_engine_context_in(struct intel_engine_cs *engine)
-{
- unsigned long flags;
-
- if (atomic_add_unless(&engine->stats.active, 1, 0))
- return;
-
- write_seqlock_irqsave(&engine->stats.lock, flags);
- if (!atomic_add_unless(&engine->stats.active, 1, 0)) {
- engine->stats.start = ktime_get();
- atomic_inc(&engine->stats.active);
- }
- write_sequnlock_irqrestore(&engine->stats.lock, flags);
-}
-
-static void intel_engine_context_out(struct intel_engine_cs *engine)
-{
- unsigned long flags;
-
- GEM_BUG_ON(!atomic_read(&engine->stats.active));
-
- if (atomic_add_unless(&engine->stats.active, -1, 1))
- return;
-
- write_seqlock_irqsave(&engine->stats.lock, flags);
- if (atomic_dec_and_test(&engine->stats.active)) {
- engine->stats.total =
- ktime_add(engine->stats.total,
- ktime_sub(ktime_get(), engine->stats.start));
- }
- write_sequnlock_irqrestore(&engine->stats.lock, flags);
-}
-
static void
execlists_check_context(const struct intel_context *ce,
const struct intel_engine_cs *engine)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/12] drm/i915/gt: Decouple inflight virtual engines
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the context is inflight, only kick the bound sibling while it
inflight and upon scheduling out the kick the rest (so that we can swap
engines on timeslicing if the previously bound engine becomes
oversubscribed).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 30 +
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e0b9a1f9eedf..e7eec78a2e55 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1410,9 +1410,8 @@ static inline void execlists_schedule_in(struct
i915_request *rq, int idx)
static void kick_siblings(struct i915_request *rq, struct intel_context *ce)
{
struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
- struct i915_request *next = READ_ONCE(ve->request);
- if (next == rq || (next && next->execution_mask & ~rq->execution_mask))
+ if (READ_ONCE(ve->request))
tasklet_hi_schedule(&ve->base.execlists.tasklet);
}
@@ -1828,18 +1827,14 @@ first_virtual_engine(struct intel_engine_cs *engine)
rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
struct i915_request *rq = READ_ONCE(ve->request);
- if (!rq) { /* lazily cleanup after another engine handled rq */
+ /* lazily cleanup after another engine handled rq */
+ if (!rq || !virtual_matches(ve, rq, engine)) {
rb_erase_cached(rb, &el->virtual);
RB_CLEAR_NODE(rb);
rb = rb_first_cached(&el->virtual);
continue;
}
- if (!virtual_matches(ve, rq, engine)) {
- rb = rb_next(rb);
- continue;
- }
-
return ve;
}
@@ -5448,7 +5443,6 @@ static void virtual_submission_tasklet(unsigned long data)
if (unlikely(!mask))
return;
- local_irq_disable();
for (n = 0; n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = READ_ONCE(ve->siblings[n]);
struct ve_node * const node = &ve->nodes[sibling->id];
@@ -5458,20 +5452,19 @@ static void virtual_submission_tasklet(unsigned long
data)
if (!READ_ONCE(ve->request))
break; /* already handled by a sibling's tasklet */
+ spin_lock_irq(&sibling->active.lock);
+
if (unlikely(!(mask & sibling->mask))) {
if (!RB_EMPTY_NODE(&node->rb)) {
- spin_lock(&sibling->active.lock);
rb_erase_cached(&node->rb,
&sibling->execlists.virtual);
RB_CLEAR_NODE(&node->rb);
- spin_unlock(&sibling->active.lock);
}
- continue;
- }
- spin_lock(&sibling->active.lock);
+ goto unlock_engine;
+ }
- if (!RB_EMPTY_NODE(&node->rb)) {
+ if (unlikely(!RB_EMPTY_NODE(&node->rb))) {
/*
* Cheat and avoid rebalancing the tree if we can
* reuse this node in situ.
@@ -5511,9 +5504,12 @@ static void virtual_submission_tasklet(unsigned long
data)
if (first && prio > sibling->execlists.queue_priority_hint)
tasklet_hi_schedule(&sibling->execlists.tasklet);
- spin_unlock(&sibling->active.lock);
+unlock_engine:
+ spin_unlock_irq(&sibling->active.lock);
+
+ if (intel_context_inflight(&ve->context))
+ break;
}
- local_irq_enable();
}
static void virtual_submit_request(struct i915_request *rq)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/12] drm/i915/gt: ce->inflight updates are now serialised
Since schedule-in and schedule-out are now both always under the tasklet
bitlock, we can reduce the individual atomic operations to simple
instructions and worry less.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 44 +
1 file changed, 19 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 07d38acacd98..ab57e9329bc1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1341,7 +1341,7 @@ __execlists_schedule_in(struct i915_request *rq)
unsigned int tag = ffs(READ_ONCE(engine->context_tag));
GEM_BUG_ON(tag == 0 || tag >= BITS_PER_LONG);
- clear_bit(tag - 1, &engine->context_tag);
+ __clear_bit(tag - 1, &engine->context_tag);
ce->lrc.ccid = tag << (GEN11_SW_CTX_ID_SHIFT - 32);
BUILD_BUG_ON(BITS_PER_LONG > GEN12_MAX_CONTEXT_HW_ID);
@@ -1368,13 +1368,10 @@ static inline void execlists_schedule_in(struct
i915_request *rq, int idx)
GEM_BUG_ON(!intel_engine_pm_is_awake(rq->engine));
trace_i915_request_in(rq, idx);
- old = READ_ONCE(ce->inflight);
- do {
- if (!old) {
- WRITE_ONCE(ce->inflight, __execlists_schedule_in(rq));
- break;
- }
- } while (!try_cmpxchg(&ce->inflight, &old, ptr_inc(old)));
+ old = ce->inflight;
+ if (!old)
+ old = __execlists_schedule_in(rq);
+ WRITE_ONCE(ce->inflight, ptr_inc(old));
GEM_BUG_ON(intel_context_inflight(ce) != rq->engine);
}
@@ -1424,12 +1421,11 @@ static void kick_siblings(struct i915_request *rq,
struct intel_context *ce)
resubmit_virtual_request(rq, ve);
}
-static inline void
-__execlists_schedule_out(struct i915_request *rq,
-struct intel_engine_cs * const engine,
-unsigned int ccid)
+static inline void __execlists_schedule_out(struct i915_request *rq)
{
struct intel_context * const ce = rq->context;
+ struct intel_engine_cs * const engine = rq->engine;
+ unsigned int ccid;
/*
* NB process_csb() is not under the engine->active.lock and hence
@@ -1437,7 +1433,7 @@ __execlists_schedule_out(struct i915_request *rq,
* refrain from doing non-trivial work here.
*/
- CE_TRACE(ce, "schedule-out, ccid:%x\n", ccid);
+ CE_TRACE(ce, "schedule-out, ccid:%x\n", ce->lrc.ccid);
/*
* If we have just completed this context, the engine may now be
@@ -1447,12 +1443,13 @@ __execlists_schedule_out(struct i915_request *rq,
i915_request_completed(rq))
intel_engine_add_retire(engine, ce->timeline);
+ ccid = ce->lrc.ccid;
ccid >>= GEN11_SW_CTX_ID_SHIFT - 32;
ccid &= GEN12_MAX_CONTEXT_HW_ID;
if (ccid < BITS_PER_LONG) {
GEM_BUG_ON(ccid == 0);
GEM_BUG_ON(test_bit(ccid - 1, &engine->context_tag));
- set_bit(ccid - 1, &engine->context_tag);
+ __set_bit(ccid - 1, &engine->context_tag);
}
intel_context_update_runtime(ce);
@@ -1473,26 +1470,23 @@ __execlists_schedule_out(struct i915_request *rq,
*/
if (ce->engine != engine)
kick_siblings(rq, ce);
-
- intel_context_put(ce);
}
static inline void
execlists_schedule_out(struct i915_request *rq)
{
struct intel_context * const ce = rq->context;
- struct intel_engine_cs *cur, *old;
- u32 ccid;
trace_i915_request_out(rq);
- ccid = rq->context->lrc.ccid;
- old = READ_ONCE(ce->inflight);
- do
- cur = ptr_unmask_bits(old, 2) ? ptr_dec(old) : NULL;
- while (!try_cmpxchg(&ce->inflight, &old, cur));
- if (!cur)
- __execlists_schedule_out(rq, old, ccid);
+ GEM_BUG_ON(!ce->inflight);
+ ce->inflight = ptr_dec(ce->inflight);
+ if (!intel_context_inflight_count(ce)) {
+ GEM_BUG_ON(ce->inflight != rq->engine);
+ __execlists_schedule_out(rq);
+ WRITE_ONCE(ce->inflight, NULL);
+ intel_context_put(ce);
+ }
i915_request_put(rq);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/12] drm/i915/gt: Decouple completed requests on unwind
Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the entire list while unwinding to
not miss any. However, if the request is completed we currently leave it
on the list [until retirement], but we could just as simply remove it
and stop treating it as active. We would only have to then traverse it
once while unwinding in quick succession.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e866b8d721ed..4eb397b0e14d 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1114,8 +1114,10 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
list_for_each_entry_safe_reverse(rq, rn,
&engine->active.requests,
sched.link) {
- if (i915_request_completed(rq))
- continue; /* XXX */
+ if (i915_request_completed(rq)) {
+ list_del_init(&rq->sched.link);
+ continue;
+ }
__i915_request_unsubmit(rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/12] drm/i915/gt: Use virtual_engine during execlists_dequeue
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single virtual engine lookup, for typical use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 209 ++--
1 file changed, 101 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 358b0b801d7c..e0b9a1f9eedf 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -454,7 +454,7 @@ static int queue_prio(const struct intel_engine_execlists
*execlists)
static inline bool need_preempt(const struct intel_engine_cs *engine,
const struct i915_request *rq,
- struct rb_node *rb)
+ const struct virtual_engine *ve)
{
int last_prio;
@@ -491,9 +491,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
rq_prio(list_next_entry(rq, sched.link)) > last_prio)
return true;
- if (rb) {
- struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ if (ve) {
bool preempt = false;
if (engine == ve->siblings[0]) { /* only preempt one sibling */
@@ -1819,6 +1817,35 @@ static bool virtual_matches(const struct virtual_engine
*ve,
return true;
}
+static struct virtual_engine *
+first_virtual_engine(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *el = &engine->execlists;
+ struct rb_node *rb = rb_first_cached(&el->virtual);
+
+ while (rb) {
+ struct virtual_engine *ve =
+ rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ struct i915_request *rq = READ_ONCE(ve->request);
+
+ if (!rq) { /* lazily cleanup after another engine handled rq */
+ rb_erase_cached(rb, &el->virtual);
+ RB_CLEAR_NODE(rb);
+ rb = rb_first_cached(&el->virtual);
+ continue;
+ }
+
+ if (!virtual_matches(ve, rq, engine)) {
+ rb = rb_next(rb);
+ continue;
+ }
+
+ return ve;
+ }
+
+ return NULL;
+}
+
static void virtual_xfer_breadcrumbs(struct virtual_engine *ve)
{
/*
@@ -1903,7 +1930,7 @@ static void defer_active(struct intel_engine_cs *engine)
static bool
need_timeslice(const struct intel_engine_cs *engine,
const struct i915_request *rq,
- const struct rb_node *rb)
+ const struct virtual_engine *ve)
{
int hint;
@@ -1912,9 +1939,7 @@ need_timeslice(const struct intel_engine_cs *engine,
hint = engine->execlists.queue_priority_hint;
- if (rb) {
- const struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ if (ve) {
const struct intel_engine_cs *inflight =
intel_context_inflight(&ve->context);
@@ -2066,6 +2091,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
struct i915_request **port = execlists->pending;
struct i915_request ** const last_port = port + execlists->port_mask;
struct i915_request * const *active = execlists->active;
+ struct virtual_engine *ve;
struct i915_request *last;
unsigned long flags;
struct rb_node *rb;
@@ -2093,26 +2119,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* and context switches) submission.
*/
spin_lock_irqsave(&engine->active.lock, flags);
-
- for (rb = rb_first_cached(&execlists->virtual); rb; ) {
- struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
- struct i915_request *rq = READ_ONCE(ve->request);
-
- if (!rq) { /* lazily cleanup after another engine handled rq */
- rb_erase_cached(rb, &execlists->virtual);
- RB_CLEAR_NODE(rb);
- rb = rb_first_cached(&execlists->virtual);
- continue;
- }
-
- if (!virtual_matches(ve, rq, engine)) {
- rb = rb_next(rb);
- continue;
- }
-
- break;
- }
+ ve = first_virtual_engine(engine);
/*
* If the queue is higher priority than the last
@@ -2140,7 +2147,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
return;
}
-
[Intel-gfx] [PATCH 08/12] drm/i915/gt: Simplify virtual engine handling for execlists_hold()
Now that the tasklet completely controls scheduling of the requests, and
we postpone scheduling out the old requests, we can keep a hanging
virtual request bound to the engine on which it hung, and remove it from
te queue. On release, it will be returned to the same engine and remain
in its queue until it is scheduled; after which point it will become
eligible for transfer to a sibling. Instead, we could opt to resubmit the
request along the virtual engine on unhold, making it eligible for load
balancing immediately -- but that seems like a pointless optimisation
for a hanging context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 055b00fd1416..07d38acacd98 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2785,35 +2785,6 @@ static bool execlists_hold(struct intel_engine_cs
*engine,
goto unlock;
}
- if (rq->engine != engine) { /* preempted virtual engine */
- struct virtual_engine *ve = to_virtual_engine(rq->engine);
-
- /*
-* intel_context_inflight() is only protected by virtue
-* of process_csb() being called only by the tasklet (or
-* directly from inside reset while the tasklet is suspended).
-* Assert that neither of those are allowed to run while we
-* poke at the request queues.
-*/
- GEM_BUG_ON(!reset_in_progress(&engine->execlists));
-
- /*
-* An unsubmitted request along a virtual engine will
-* remain on the active (this) engine until we are able
-* to process the context switch away (and so mark the
-* context as no longer in flight). That cannot have happened
-* yet, otherwise we would not be hanging!
-*/
- spin_lock(&ve->base.active.lock);
- GEM_BUG_ON(intel_context_inflight(rq->context) != engine);
- GEM_BUG_ON(ve->request != rq);
- ve->request = NULL;
- spin_unlock(&ve->base.active.lock);
- i915_request_put(rq);
-
- rq->engine = engine;
- }
-
/*
* Transfer this request onto the hold queue to prevent it
* being resumbitted to HW (and potentially completed) before we have
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/12] drm/i915/gt: Check for a completed last request once
Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 4eb397b0e14d..7bdbfac26d7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2137,12 +2137,11 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
*/
if ((last = *active)) {
- if (need_preempt(engine, last, rb)) {
- if (i915_request_completed(last)) {
- tasklet_hi_schedule(&execlists->tasklet);
- return;
- }
+ if (i915_request_completed(last) &&
+ !list_is_last(&last->sched.link, &engine->active.requests))
+ return;
+ if (need_preempt(engine, last, rb)) {
ENGINE_TRACE(engine,
"preempting last=%llx:%lld, prio=%d,
hint=%d\n",
last->fence.context,
@@ -2170,11 +2169,6 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
last = NULL;
} else if (need_timeslice(engine, last, rb) &&
timeslice_expired(execlists, last)) {
- if (i915_request_completed(last)) {
- tasklet_hi_schedule(&execlists->tasklet);
- return;
- }
-
ENGINE_TRACE(engine,
"expired last=%llx:%lld, prio=%d, hint=%d,
yield?=%s\n",
last->fence.context,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/12] drm/i915/gt: Resubmit the virtual engine on schedule-out
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
By keeping the unwind order intact on the local engine, we can preserve
data dependency ordering while doing a preempt-to-busy pass until we
have determined the new ELSP. This means that if we try to timeslice
between a virtual engine and a data-dependent ordinary request, the pair
will maintain their relative ordering and we will avoid the
resubmission, cancelling the timeslicing until further change.
The dilemma though is that we then may end up in a situation where the
'demotion' of the virtual request to an ordinary request in the engine
queue results in filling the ELSP[] with virtual requests instead of
spreading the load across the engines. To compensate for this, we mark
each virtual request and refuse to resubmit a virtual request in the
secondary ELSP slots, thus forcing subsequent virtual requests to be
scheduled out after timeslicing. By delaying the decision until we
schedule out, we will avoid unnecessary resubmission.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 118 -
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
2 files changed, 75 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 1f4483c0bbdd..055b00fd1416 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1119,53 +1119,23 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
__i915_request_unsubmit(rq);
- /*
-* Push the request back into the queue for later resubmission.
-* If this request is not native to this physical engine (i.e.
-* it came from a virtual source), push it back onto the virtual
-* engine so that it can be moved across onto another physical
-* engine as load dictates.
-*/
- if (likely(rq->execution_mask == engine->mask)) {
- GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
- if (rq_prio(rq) != prio) {
- prio = rq_prio(rq);
- pl = i915_sched_lookup_priolist(engine, prio);
- }
-
GEM_BUG_ON(RB_EMPTY_ROOT(&engine->execlists.queue.rb_root));
-
- list_move(&rq->sched.link, pl);
- set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
+ GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
+ if (rq_prio(rq) != prio) {
+ prio = rq_prio(rq);
+ pl = i915_sched_lookup_priolist(engine, prio);
+ }
+ GEM_BUG_ON(RB_EMPTY_ROOT(&engine->execlists.queue.rb_root));
- /* Check in case we rollback so far we wrap [size/2] */
- if (intel_ring_direction(rq->ring,
-intel_ring_wrap(rq->ring,
-rq->tail),
-rq->ring->tail) > 0)
- rq->context->lrc.desc |= CTX_DESC_FORCE_RESTORE;
+ list_move(&rq->sched.link, pl);
+ set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
- active = rq;
- } else {
- struct intel_engine_cs *owner = rq->context->engine;
+ /* Check in case we rollback so far we wrap [size/2] */
+ if (intel_ring_direction(rq->ring,
+intel_ring_wrap(rq->ring, rq->tail),
+rq->ring->tail) > 0)
+ rq->context->lrc.desc |= CTX_DESC_FORCE_RESTORE;
- /*
-* Decouple the virtual breadcrumb before moving it
-* back to the virtual engine -- we don't want the
-* request to complete in the background and try
-* and cancel the breadcrumb on the virtual engine
-* (instead of the old engine where it is linked)!
-*/
- if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
-&rq->fence.flags)) {
- spin_lock_nested(&rq->lock,
-SINGLE_DEPTH_NESTING);
- i915_request_cancel_breadcrumb(rq);
- spin_unlock(&rq->lock);
- }
- WRITE_ONCE(rq->engine, owner);
- owner->submit_re
[Intel-gfx] [PATCH 03/12] drm/i915/gt: Replace direct submit with direct call to tasklet
Rather than having special case code for opportunistically calling
process_csb() and performing a direct submit while holding the engine
spinlock for submitting the request, simply call the tasklet directly.
This allows us to retain the direct submission path, including the CS
draining to allow fast/immediate submissions, without requiring any
duplicated code paths.
The trickiest part here is to ensure that paired operations (such as
schedule_in/schedule_out) remain under consistent locking domains,
e.g. when pulled outside of the engine->active.lock
v2: Use bh kicking, see commit 3c53776e29f8 ("Mark HI and TASKLET
softirq synchronous").
v3: Update engine-reset to be tasklet aware
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 35 +++---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 20 +--
drivers/gpu/drm/i915/gt/intel_lrc.c | 119 ++
drivers/gpu/drm/i915/gt/intel_reset.c | 60 +
drivers/gpu/drm/i915/gt/intel_reset.h | 2 +
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 7 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 27 ++--
drivers/gpu/drm/i915/gt/selftest_reset.c | 8 +-
drivers/gpu/drm/i915/i915_request.c | 2 +
drivers/gpu/drm/i915/selftests/i915_request.c | 6 +-
12 files changed, 149 insertions(+), 143 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 41784df51e58..a5fda0cef118 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -398,12 +398,14 @@ static bool __reset_engine(struct intel_engine_cs *engine)
if (!intel_has_reset_engine(gt))
return false;
+ local_bh_disable();
if (!test_and_set_bit(I915_RESET_ENGINE + engine->id,
>->reset.flags)) {
- success = intel_engine_reset(engine, NULL) == 0;
+ success = __intel_engine_reset_bh(engine, NULL) == 0;
clear_and_wake_up_bit(I915_RESET_ENGINE + engine->id,
>->reset.flags);
}
+ local_bh_enable();
return success;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index dd15a799f9d6..35de3f8566de 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2362,7 +2362,9 @@ static void eb_request_add(struct i915_execbuffer *eb)
__i915_request_skip(rq);
}
+ local_bh_disable();
__i915_request_queue(rq, &attr);
+ local_bh_enable();
/* Try to clean up the client's timeline after submitting the request */
if (prev)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 7bf2f76212f0..b024ac1debc7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -903,32 +903,39 @@ static unsigned long stop_timeout(const struct
intel_engine_cs *engine)
return READ_ONCE(engine->props.stop_timeout_ms);
}
-int intel_engine_stop_cs(struct intel_engine_cs *engine)
+static int __intel_engine_stop_cs(struct intel_engine_cs *engine,
+ int fast_timeout_us,
+ int slow_timeout_ms)
{
struct intel_uncore *uncore = engine->uncore;
- const u32 base = engine->mmio_base;
- const i915_reg_t mode = RING_MI_MODE(base);
+ const i915_reg_t mode = RING_MI_MODE(engine->mmio_base);
int err;
+ intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
+ err = __intel_wait_for_register_fw(engine->uncore, mode,
+ MODE_IDLE, MODE_IDLE,
+ fast_timeout_us,
+ slow_timeout_ms,
+ NULL);
+
+ /* A final mmio read to let GPU writes be hopefully flushed to memory */
+ intel_uncore_posting_read_fw(uncore, mode);
+ return err;
+}
+
+int intel_engine_stop_cs(struct intel_engine_cs *engine)
+{
+ int err = 0;
+
if (INTEL_GEN(engine->i915) < 3)
return -ENODEV;
ENGINE_TRACE(engine, "\n");
-
- intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
-
- err = 0;
- if (__intel_wait_for_register_fw(uncore,
-mode, MODE_IDLE, MODE_IDLE,
-1000, stop_timeout(engine),
-NULL)) {
+ if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
ENGINE_TRACE(engine, "ti
Re: [Intel-gfx] [PATCH 18/23] drm/i915: Dirty hack to fix selftests locking inversion
On 07/07/2020 11:19, Maarten Lankhorst wrote: Op 03-07-2020 om 15:48 schreef Tvrtko Ursulin: On 03/07/2020 13:22, Maarten Lankhorst wrote: Some i915 selftests still use i915_vma_lock() as inner lock, and intel_context_create_request() intel_timeline->mutex as outer lock. Fortunately for selftests this is not an issue, they should be fixed but we can move ahead and cleanify lockdep now. Mentions and existence of "dirty hacks" will hopefully be removed from the series before it can be considered merge ready? Regards, Tvrtko Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_context.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index 64948386630f..fe9fff5a63b1 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -459,6 +459,18 @@ struct i915_request *intel_context_create_request(struct intel_context *ce) rq = i915_request_create(ce); intel_context_unpin(ce); + if (IS_ERR(rq)) + return rq; + + /* + * timeline->mutex should be the inner lock, but is used as outer lock. + * Hack around this to shut up lockdep in selftests.. + */ + lockdep_unpin_lock(&ce->timeline->mutex, rq->cookie); + mutex_release(&ce->timeline->mutex.dep_map, _RET_IP_); + mutex_acquire(&ce->timeline->mutex.dep_map, SINGLE_DEPTH_NESTING, 0, _RET_IP_); + rq->cookie = lockdep_pin_lock(&ce->timeline->mutex); + return rq; } Hey, We're trying to invert the locking order with vma lock vs request lock, while this is a hack, it will not affect normal running code, it's only meant to shut up lockdep in the selftests. This is mainly so we can fix the selftests one by one, without breaking the world. Ideally when mm.obj lands, we already corrected the lock ordering. We may keep this macro for selftests, but until lock reordering in selftests is complete we will need this temporarily. Is there a relationship between obj->mm.lock and this particular lock inversion? I don't see it. It will become critical to have selftests adjusted to proper locking order for every which will/can trigger eviction. But okay,if you want to stage the pieces perhaps it is acceptable. As previous patch in the series removes intel_context_create_request usages outside selftests I suggest you mention this in this commit message, as part of justification why it is safe. Also it would be good to wrap intel_context_create_request in a selftest #ifdef so that accidental usage is prevented in the inter-rim stages of refactoring. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/23] drm/i915: Dirty hack to fix selftests locking inversion
Op 07-07-2020 om 12:56 schreef Tvrtko Ursulin: > > On 07/07/2020 11:19, Maarten Lankhorst wrote: >> Op 03-07-2020 om 15:48 schreef Tvrtko Ursulin: >>> >>> On 03/07/2020 13:22, Maarten Lankhorst wrote: Some i915 selftests still use i915_vma_lock() as inner lock, and intel_context_create_request() intel_timeline->mutex as outer lock. Fortunately for selftests this is not an issue, they should be fixed but we can move ahead and cleanify lockdep now. >>> >>> Mentions and existence of "dirty hacks" will hopefully be removed from the >>> series before it can be considered merge ready? >>> >>> Regards, >>> >>> Tvrtko >>> Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_context.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index 64948386630f..fe9fff5a63b1 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -459,6 +459,18 @@ struct i915_request *intel_context_create_request(struct intel_context *ce) rq = i915_request_create(ce); intel_context_unpin(ce); + if (IS_ERR(rq)) + return rq; + + /* + * timeline->mutex should be the inner lock, but is used as outer lock. + * Hack around this to shut up lockdep in selftests.. + */ + lockdep_unpin_lock(&ce->timeline->mutex, rq->cookie); + mutex_release(&ce->timeline->mutex.dep_map, _RET_IP_); + mutex_acquire(&ce->timeline->mutex.dep_map, SINGLE_DEPTH_NESTING, 0, _RET_IP_); + rq->cookie = lockdep_pin_lock(&ce->timeline->mutex); + return rq; } >> >> Hey, >> >> We're trying to invert the locking order with vma lock vs request lock, >> while this is a hack, >> it will not affect normal running code, it's only meant to shut up lockdep >> in the selftests. >> >> This is mainly so we can fix the selftests one by one, without breaking the >> world. Ideally >> when mm.obj lands, we already corrected the lock ordering. We may keep this >> macro for selftests, >> but until lock reordering in selftests is complete we will need this >> temporarily. > > Is there a relationship between obj->mm.lock and this particular lock > inversion? I don't see it. It will become critical to have selftests adjusted > to proper locking order for every which will/can trigger eviction. But > okay,if you want to stage the pieces perhaps it is acceptable. It's the request timeline lock being inverted, not the mm.lock. :) It needs fixing, because we want to wire ww everywhere, but it should be ok in the meantime for just selftests. For mm.lock removal, we will need to fix this completely, as this function will use its own ww context, and all pins should be fixed to use the scope of the ww lock only. > As previous patch in the series removes intel_context_create_request usages > outside selftests I suggest you mention this in this commit message, as part > of justification why it is safe. True. > Also it would be good to wrap intel_context_create_request in a selftest > #ifdef so that accidental usage is prevented in the inter-rim stages of > refactoring. Sounds good. :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/12] drm/i915/gt: Decouple completed requests on unwind
== Series Details == Series: series starting with [01/12] drm/i915/gt: Decouple completed requests on unwind URL : https://patchwork.freedesktop.org/series/79183/ State : warning == Summary == $ dim checkpatch origin/drm-tip fbb4ac3d3d2f drm/i915/gt: Decouple completed requests on unwind 5a59199cf602 drm/i915/gt: Check for a completed last request once f752b802f50a drm/i915/gt: Replace direct submit with direct call to tasklet 679e8bca48d4 drm/i915/gt: Use virtual_engine during execlists_dequeue 5a956e7c7bdc drm/i915/gt: Decouple inflight virtual engines b115e301df47 drm/i915/gt: Defer schedule_out until after the dequeue ee73ef387ef9 drm/i915/gt: Resubmit the virtual engine on schedule-out fde7899263f2 drm/i915/gt: Simplify virtual engine handling for execlists_hold() 20c1f787e92d drm/i915/gt: ce->inflight updates are now serialised e22f71e6b331 drm/i915/gt: Drop atomic for engine->fw_active tracking 8e9a40de0f5d drm/i915/gt: Extract busy-stats for ring-scheduler -:12: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #12: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 95 lines checked 07df3fb1ebbe drm/i915/gt: Convert stats.active to plain unsigned int ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/12] drm/i915/gt: Decouple completed requests on unwind
== Series Details == Series: series starting with [01/12] drm/i915/gt: Decouple completed requests on unwind URL : https://patchwork.freedesktop.org/series/79183/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. -O:drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion -O:drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v5,1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status
== Series Details == Series: series starting with [v5,1/2] drm/i915/dp: Helper for checking DDI_BUF_CTL Idle status URL : https://patchwork.freedesktop.org/series/79018/ State : success == Summary == CI Bug Log - changes from CI_DRM_8688_full -> Patchwork_18062_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18062_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@cpuset-basic-small-copy: - shard-snb: [PASS][1] -> [TIMEOUT][2] ([i915#1958] / [i915#2119]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-snb5/igt@gem_mmap_...@cpuset-basic-small-copy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-snb2/igt@gem_mmap_...@cpuset-basic-small-copy.html * igt@kms_addfb_basic@addfb25-modifier-no-flag: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] / [i915#95]) +19 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-apl3/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-apl7/igt@kms_addfb_ba...@addfb25-modifier-no-flag.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-rapid-movement: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#62] / [i915#92]) +22 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-64x64-rapid-movement.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-64x64-rapid-movement.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#93] / [i915#95]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-xtiled: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-apl4/igt@kms_draw_...@draw-method-rgb565-mmap-wc-xtiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-apl6/igt@kms_draw_...@draw-method-rgb565-mmap-wc-xtiled.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#79]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-skl6/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-skl3/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render: - shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#402]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-tglb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-tglb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-gtt: - shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-tglb1/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-mmap-gtt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-tglb2/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-cpu: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +7 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-skl7/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-skl3/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-skl10/igt@kms_...@bpc-switch-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-skl1/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([i915#1185] / [i915#250]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/shard-iclb1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18062/shard-iclb3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html - shard-kbl: [PASS][23] -> [DM
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/12] drm/i915/gt: Decouple completed requests on unwind
== Series Details ==
Series: series starting with [01/12] drm/i915/gt: Decouple completed requests
on unwind
URL : https://patchwork.freedesktop.org/series/79183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8709 -> Patchwork_18093
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/index.html
Known issues
Here are the changes found in Patchwork_18093 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] ([i915#1250] /
[i915#1436])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-bsw-nick/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-bsw-nick/igt@debugfs_test@read_all_entries.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@basic:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-tgl-y/igt@gem_flink_ba...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-apl-guc/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-apl-guc/igt@i915_module_l...@reload.html
- fi-tgl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#402])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-tgl-u2/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
Possible fixes
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@i915_module_load@reload:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-kbl-x1275/igt@i915_module_l...@reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-kbl-x1275/igt@i915_module_l...@reload.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
Re: [Intel-gfx] [PATCH 1/4] drm/i915/fbc: Use the correct plane stride
On Mon, Jul 06, 2020 at 08:53:06PM +, Souza, Jose wrote:
> On Fri, 2020-07-03 at 14:38 +0300, Ville Syrjälä wrote:
> > On Thu, Jul 02, 2020 at 11:24:04PM +, Souza, Jose wrote:
> > > On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Consult the actual plane stride instead of the fb stride. The two
> > > > will disagree when we remap the gtt. The plane stride is what the
> > > > hw will be fed so that's what we should look at for the FBC
> > > > retrictions/cfb allocation.
> > > >
> > > > Since we no longer require a fence we are going to attempt using
> > > > FBC with remapping, and so we should look at correct stride.
> > > >
> > > > With 90/270 degree rotation the plane stride is stored in units
> > > > of pixels, so we need to conver it to bytes for the purposes
> > > > of calculating the cfb stride. Not entirely sure if this matches
> > > > the hw behaviour though. Need to reverse engineer that at some
> > > > point...
> > > >
> > > > We also need to reorder the pixel format check vs. stride check
> > > > to avoid triggering a spurious WARN(stride & 63) with cpp==1 and
> > > > plane stride==32.
> > > >
> > > > v2: Try to deal with rotated stride and related WARN
> > > >
> > >
> > > Reviewed-by: José Roberto de Souza
> > >
> > > > Cc: José Roberto de Souza
> > > > Fixes: 691f7ba58d52 ("drm/i915/display/fbc: Make fences a nice-to-have
> > > > for GEN9+")
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_fbc.c | 16 ++--
> > > > 1 file changed, 10 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > index 69a0682ddb6a..d30c2a389294 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > @@ -695,9 +695,13 @@ static void intel_fbc_update_state_cache(struct
> > > > intel_crtc *crtc,
> > > > cache->plane.pixel_blend_mode =
> > > > plane_state->hw.pixel_blend_mode;
> > > >
> > > > cache->fb.format = fb->format;
> > > > - cache->fb.stride = fb->pitches[0];
> > > > cache->fb.modifier = fb->modifier;
> > > >
> > > > + /* FIXME is this correct? */
> > > > + cache->fb.stride = plane_state->color_plane[0].stride;
> > > > + if (drm_rotation_90_or_270(plane_state->hw.rotation))
> > >
> > > If it was wrong our CI would caught this in BDW or SNB for example.
> >
> > Not really. Well, certainly not on pre-skl since they don't do 90/270
> > rotation. And probably not even on skl+ since any wrong assumption
>
> Checking rotation_is_valid() GEN5 up to GEN8 allows 90/270 rotation.
The display engine on pre-skl does not support 90/270 rotaiton *at all*.
>
>
> > about how the cfb stride is calculated by the hw would just cause it
> > to scribble over stolen memory we didn't allocate. So unless we've
> > started to use stolen more extensively in recent times such problems
> > would probably go unnoticed.
> >
> > > > + cache->fb.stride *= fb->format->cpp[0];
> > > > +
> > > > /* FBC1 compression interval: arbitrary choice of 1 second */
> > > > cache->interval =
> > > > drm_mode_vrefresh(&crtc_state->hw.adjusted_mode);
> > > >
> > > > @@ -797,6 +801,11 @@ static bool intel_fbc_can_activate(struct
> > > > intel_crtc *crtc)
> > > > return false;
> > > > }
> > > >
> > > > + if (!pixel_format_is_valid(dev_priv, cache->fb.format->format))
> > > > {
> > > > + fbc->no_fbc_reason = "pixel format is invalid";
> > > > + return false;
> > > > + }
> > > > +
> > > > if (!rotation_is_valid(dev_priv, cache->fb.format->format,
> > > >cache->plane.rotation)) {
> > > > fbc->no_fbc_reason = "rotation unsupported";
> > > > @@ -813,11 +822,6 @@ static bool intel_fbc_can_activate(struct
> > > > intel_crtc *crtc)
> > > > return false;
> > > > }
> > > >
> > > > - if (!pixel_format_is_valid(dev_priv, cache->fb.format->format))
> > > > {
> > > > - fbc->no_fbc_reason = "pixel format is invalid";
> > > > - return false;
> > > > - }
> > > > -
> > > > if (cache->plane.pixel_blend_mode != DRM_MODE_BLEND_PIXEL_NONE
> > > > &&
> > > > cache->fb.format->has_alpha) {
> > > > fbc->no_fbc_reason = "per-pixel alpha blending is
> > > > incompatible with FBC";
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value
On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: > Hi, > > Thank you for your review and sorry for the slow reply. No problem for me, I didn't hold my breath :-) > > > diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c > > > index 43b1fc634af1..80d0f9c64f9d 100644 > > > --- a/drivers/pwm/pwm-lpss.c > > > +++ b/drivers/pwm/pwm-lpss.c > > > @@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip > > > *lpwm, struct pwm_device *pwm, > > > freq *= base_unit_range; > > > base_unit = DIV_ROUND_CLOSEST_ULL(freq, c); > > > > DIV_ROUND_CLOSEST_ULL is most probably wrong, too. But I didn't spend > > the time to actually confirm that. > > Yes I saw your comment elsewhere that the PWM API defines rounding > in a certain direction, but fixing that falls outside of this patch. Yeah, sure. > [...] > I hope this helps to explain what is going on a bit. I will try to make sense of that and reply to the patch directly when I succeeded. > ### > > As for the behavior on base_unit==0 in the get_state method, > as mentioned above I wrote that when I did not fully understood > how the controller works. > > We really should never encounter this. > > But if we do then I think closest to the truth would be: > > state->period = UINT_MAX; > state->duty_cycle = 0; I'd say state->period = 1 & state->duty_cycle = 0 is a better representation. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 11/15] pwm: crc: Implement get_state() method
Hello Hans, On Mon, Jul 06, 2020 at 11:05:20PM +0200, Hans de Goede wrote: > Before I post a new version of this patch-set, you have only responded > to some of the PWM patches in this set. Do you have any remarks on the > other PWM patches ? I stopped looking at them as I hoped someone would appear with a datasheet. Given that this probably won't happen I can take a look at the remaining patches. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 09/15] pwm: crc: Enable/disable PWM output on enable/disable
Hello,
On Sat, Jun 20, 2020 at 02:17:52PM +0200, Hans de Goede wrote:
> The pwm-crc code is using 2 different enable bits:
> 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
> 2. bit 0 of the BACKLIGHT_EN register
>
> So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
> this commit makes crc_pwm_disable() clear it on disable and makes
> crc_pwm_enable() set it again on re-enable.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v3:
> - Remove paragraph about tri-stating the output from the commit message,
> we don't have a datasheet so this was just an unfounded guess
> ---
> drivers/pwm/pwm-crc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
> index 81232da0c767..b72008c9b072 100644
> --- a/drivers/pwm/pwm-crc.c
> +++ b/drivers/pwm/pwm-crc.c
> @@ -54,7 +54,9 @@ static int crc_pwm_calc_clk_div(int period_ns)
> static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
> {
> struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
> + int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
>
> + regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div | PWM_OUTPUT_ENABLE);
> regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
>
> return 0;
> @@ -63,8 +65,10 @@ static int crc_pwm_enable(struct pwm_chip *c, struct
> pwm_device *pwm)
> static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
> {
> struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
> + int div = crc_pwm_calc_clk_div(pwm_get_period(pwm));
>
> regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
> + regmap_write(crc_pwm->regmap, PWM0_CLK_DIV, div);
> }
>
> static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
In the absence of documentation this looks reasonable.
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 15/15] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller
Hello Hans,
On Sat, Jun 20, 2020 at 02:17:58PM +0200, Hans de Goede wrote:
> Now that the PWM drivers which we use have been converted to the atomic
> PWM API, we can move the i915 panel code over to using the atomic PWM API.
Note that there is no hard dependency, the atomic API should work just
fine even with a non-converted driver. (Of course a converted driver
behaves better, but the i915 using the atomic API with a non-converted
driver is just as good as the legacy API with the same driver.)
So regarding your plan to get this series in soon: There is no hard need
to halt the efforts for the drm part if the pwm patches take a bit
longer (or vice versa).
> The removes a long standing FIXME and this removes a flicker where
> the backlight brightness would jump to 100% when i915 loads even if
> using the fastset path.
>
> Signed-off-by: Hans de Goede
> ---
> .../drm/i915/display/intel_display_types.h| 3 +-
> drivers/gpu/drm/i915/display/intel_panel.c| 73 +--
> 2 files changed, 37 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index de32f9efb120..4bd9981e70a1 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -28,6 +28,7 @@
>
> #include
> #include
> +#include
> #include
>
> #include
> @@ -223,7 +224,7 @@ struct intel_panel {
> bool util_pin_active_low; /* bxt+ */
> u8 controller; /* bxt+ only */
> struct pwm_device *pwm;
> - int pwm_period_ns;
> + struct pwm_state pwm_state;
>
> /* DPCD backlight */
> u8 pwmgen_bit_count;
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index cb28b9908ca4..a0f76343f381 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -592,10 +592,11 @@ static u32 bxt_get_backlight(struct intel_connector
> *connector)
> static u32 pwm_get_backlight(struct intel_connector *connector)
> {
> struct intel_panel *panel = &connector->panel;
> - int duty_ns;
> + int duty_ns, period_ns;
>
> duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
> - return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
> + period_ns = pwm_get_period(panel->backlight.pwm);
The transformation is correct, but using
pwm_get_state(pwm, &state);
duty_ns = state.duty_cycle;
period_ns = state.period;
is a bit more effective as it calls pwm_get_state() only once.
There is a function pwm_get_relative_duty_cycle which is similar (with
scale = 100) just used different rounding.
> + return DIV_ROUND_UP(duty_ns * 100, period_ns);
> }
>
> static void lpt_set_backlight(const struct drm_connector_state *conn_state,
> u32 level)
> @@ -669,10 +670,10 @@ static void bxt_set_backlight(const struct
> drm_connector_state *conn_state, u32
> static void pwm_set_backlight(const struct drm_connector_state *conn_state,
> u32 level)
> {
> struct intel_panel *panel =
> &to_intel_connector(conn_state->connector)->panel;
> - int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
>
> - pwm_config(panel->backlight.pwm, duty_ns,
> -panel->backlight.pwm_period_ns);
> + panel->backlight.pwm_state.duty_cycle =
> + DIV_ROUND_UP(level * panel->backlight.pwm_state.period, 100);
> + pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
> }
>
> static void
> @@ -841,10 +842,8 @@ static void pwm_disable_backlight(const struct
> drm_connector_state *old_conn_sta
> struct intel_connector *connector =
> to_intel_connector(old_conn_state->connector);
> struct intel_panel *panel = &connector->panel;
>
> - /* Disable the backlight */
> - intel_panel_actually_set_backlight(old_conn_state, 0);
> - usleep_range(2000, 3000);
> - pwm_disable(panel->backlight.pwm);
> + panel->backlight.pwm_state.enabled = false;
> + pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
Did you drop intel_panel_actually_set_backlight and the sleep on purpose?
> }
>
> void intel_panel_disable_backlight(const struct drm_connector_state
> *old_conn_state)
> [...]
> @@ -1916,36 +1919,30 @@ static int pwm_setup_backlight(struct intel_connector
> *connector,
> return -ENODEV;
> }
>
> - panel->backlight.pwm_period_ns = NSEC_PER_SEC /
> - get_vbt_pwm_freq(dev_priv);
> -
> - /*
> - * FIXME: pwm_apply_args() should be removed when switching to
> - * the atomic PWM API.
> - */
> - pwm_apply_args(panel->backlight.pwm);
> -
> panel->backlight.max = 100; /* 100% */
> panel->backlight.min = get_backlight_min_vbt
[Intel-gfx] [PATCH v1] drm/i915: Fix spelling mistake in i915_reg.h
Fix typo: "TRIGER" --> "TRIGGER" The two misplelled macros: 1) OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK 2) OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK are not used in any other sources of the kernel, so this change can be consider only a local change for the i915_reg.h file. Signed-off-by: Flavio Suligoi Reviewed-by: Chris Wilson --- v1: add "Reviewed-by: Chris Wilson " drivers/gpu/drm/i915/i915_reg.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 9d6536afc94b..c2153364724a 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -868,7 +868,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define OAREPORTTRIG1 _MMIO(0x2740) #define OAREPORTTRIG1_THRESHOLD_MASK 0x -#define OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK 0x /* 0=level */ +#define OAREPORTTRIG1_EDGE_LEVEL_TRIGGER_SELECT_MASK 0x /* 0=level */ #define OAREPORTTRIG2 _MMIO(0x2744) #define OAREPORTTRIG2_INVERT_A_0 (1 << 0) @@ -921,7 +921,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define OAREPORTTRIG5 _MMIO(0x2750) #define OAREPORTTRIG5_THRESHOLD_MASK 0x -#define OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK 0x /* 0=level */ +#define OAREPORTTRIG5_EDGE_LEVEL_TRIGGER_SELECT_MASK 0x /* 0=level */ #define OAREPORTTRIG6 _MMIO(0x2754) #define OAREPORTTRIG6_INVERT_A_0 (1 << 0) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix spelling mistake in i915_reg.h (rev2)
== Series Details == Series: drm/i915: Fix spelling mistake in i915_reg.h (rev2) URL : https://patchwork.freedesktop.org/series/79156/ State : failure == Summary == Applying: drm/i915: Fix spelling mistake in i915_reg.h Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_reg.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_reg.h No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 09/36] drm: i915: fix common struct sg_table related issues
Hi
On 19.06.2020 12:36, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called with the original number of the entries
> passed to the dma_map_sg().
>
> struct sg_table is a common structure used for describing a non-contiguous
> memory buffer, used commonly in the DRM and graphics subsystems. It
> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
> and DMA mapped pages (nents entry).
>
> It turned out that it was a common mistake to misuse nents and orig_nents
> entries, calling DMA-mapping functions with a wrong number of entries or
> ignoring the number of mapped entries returned by the dma_map_sg()
> function.
>
> This driver creatively uses sg_table->orig_nents to store the size of the
> allocated scatterlist and ignores the number of the entries returned by
> dma_map_sg function. The sg_table->orig_nents is (mis)used to properly
> free the (over)allocated scatterlist.
>
> This patch only introduces the common DMA-mapping wrappers operating
> directly on the struct sg_table objects to the dmabuf related functions,
> so the other drivers, which might share buffers with i915 could rely on
> the properly set nents and orig_nents values.
>
> Signed-off-by: Marek Szyprowski
May I ask for a review/ack/comment for this patch?
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +++
> drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +++
> 2 files changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 2679380159fc..8a988592715b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -48,12 +48,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
> dma_buf_attachment *attachme
> src = sg_next(src);
> }
>
> - if (!dma_map_sg_attrs(attachment->dev,
> - st->sgl, st->nents, dir,
> - DMA_ATTR_SKIP_CPU_SYNC)) {
> - ret = -ENOMEM;
> + ret = dma_map_sgtable(attachment->dev, st, dir, DMA_ATTR_SKIP_CPU_SYNC);
> + if (ret)
> goto err_free_sg;
> - }
>
> return st;
>
> @@ -73,9 +70,7 @@ static void i915_gem_unmap_dma_buf(struct
> dma_buf_attachment *attachment,
> {
> struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
>
> - dma_unmap_sg_attrs(attachment->dev,
> -sg->sgl, sg->nents, dir,
> -DMA_ATTR_SKIP_CPU_SYNC);
> + dma_unmap_sgtable(attachment->dev, sg, dir, DMA_ATTR_SKIP_CPU_SYNC);
> sg_free_table(sg);
> kfree(sg);
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> index debaf7b18ab5..be30b27e2926 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
> @@ -28,10 +28,9 @@ static struct sg_table *mock_map_dma_buf(struct
> dma_buf_attachment *attachment,
> sg = sg_next(sg);
> }
>
> - if (!dma_map_sg(attachment->dev, st->sgl, st->nents, dir)) {
> - err = -ENOMEM;
> + err = dma_map_sgtable(attachment->dev, st, dir, 0);
> + if (err)
> goto err_st;
> - }
>
> return st;
>
> @@ -46,7 +45,7 @@ static void mock_unmap_dma_buf(struct dma_buf_attachment
> *attachment,
> struct sg_table *st,
> enum dma_data_direction dir)
> {
> - dma_unmap_sg(attachment->dev, st->sgl, st->nents, dir);
> + dma_unmap_sgtable(attachment->dev, st, dir, 0);
> sg_free_table(st);
> kfree(st);
> }
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/12] drm/i915/gt: Decouple completed requests on unwind
== Series Details == Series: series starting with [01/12] drm/i915/gt: Decouple completed requests on unwind URL : https://patchwork.freedesktop.org/series/79183/ State : success == Summary == CI Bug Log - changes from CI_DRM_8709_full -> Patchwork_18093_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18093_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-concurrent0: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#1930]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-glk1/igt@gem_exec_re...@basic-concurrent0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html * igt@gem_exec_whisper@basic-contexts-priority: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-glk5/igt@gem_exec_whis...@basic-contexts-priority.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-glk8/igt@gem_exec_whis...@basic-contexts-priority.html * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1635] / [i915#95]) +13 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-apl8/igt@kms_big...@x-tiled-8bpp-rotate-0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-apl7/igt@kms_big...@x-tiled-8bpp-rotate-0.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-glk5/igt@kms_big...@y-tiled-64bpp-rotate-180.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_color@pipe-a-gamma: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#93] / [i915#95]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-kbl2/igt@kms_co...@pipe-a-gamma.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-kbl4/igt@kms_co...@pipe-a-gamma.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-skl7/igt@kms_co...@pipe-c-ctm-0-25.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-skl2/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#49]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-skl5/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-wc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-skl7/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-wc.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-a-coverage-vs-premult-vs-constant: - shard-kbl: [PASS][17] -> [DMESG-FAIL][18] ([fdo#108145] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-kbl3/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-kbl6/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html - shard-apl: [PASS][19] -> [DMESG-FAIL][20] ([fdo#108145] / [i915#1635] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-apl3/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-apl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8709/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18093/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel
[Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
If we assign obj->filp, we believe that the create vgem bo is native and
allow direct operations like mmap() assuming it behaves as backed by a
shmemfs inode. When imported from a dmabuf, the obj->pages are
not always meaningful and the shmemfs backing store misleading.
Note, that regular mmap access to a vgem bo is via the dumb buffer API,
and that rejects attempts to mmap an imported dmabuf,
drm_gem_dumb_map_offset():
if (obj->import_attach) return -EINVAL;
So the only route by which we might accidentally allow mmapping of an
imported buffer is via vgem_prime_mmap(), which checked for
obj->filp assuming that it would be NULL.
Well it would had it been updated to use the common
drm_gem_dum_map_offset() helper, instead it has
vgem_gem_dumb_map():
if (!obj->filp) return -EINVAL;
falling foul of the same trap as above.
Reported-by: Lepton Wu
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Signed-off-by: Chris Wilson
Cc: Lepton Wu
Cc: Daniel Vetter
Cc: Christian König
Cc: Thomas Hellström (Intel)
Cc: # v4.13+
---
drivers/gpu/drm/vgem/vgem_drv.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 909eba43664a..eb3b7cdac941 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -91,7 +91,7 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
ret = 0;
}
mutex_unlock(&obj->pages_lock);
- if (ret) {
+ if (ret && obj->base.filp) {
struct page *page;
page = shmem_read_mapping_page(
@@ -157,7 +157,8 @@ static void vgem_postclose(struct drm_device *dev, struct
drm_file *file)
}
static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
- unsigned long size)
+struct file *shmem,
+unsigned long size)
{
struct drm_vgem_gem_object *obj;
int ret;
@@ -166,11 +167,8 @@ static struct drm_vgem_gem_object
*__vgem_gem_create(struct drm_device *dev,
if (!obj)
return ERR_PTR(-ENOMEM);
- ret = drm_gem_object_init(dev, &obj->base, roundup(size, PAGE_SIZE));
- if (ret) {
- kfree(obj);
- return ERR_PTR(ret);
- }
+ drm_gem_private_object_init(dev, &obj->base, size);
+ obj->base.filp = shmem;
mutex_init(&obj->pages_lock);
@@ -189,11 +187,20 @@ static struct drm_gem_object *vgem_gem_create(struct
drm_device *dev,
unsigned long size)
{
struct drm_vgem_gem_object *obj;
+ struct file *shmem;
int ret;
- obj = __vgem_gem_create(dev, size);
- if (IS_ERR(obj))
+ size = roundup(size, PAGE_SIZE);
+
+ shmem = shmem_file_setup(DRIVER_NAME, size, VM_NORESERVE);
+ if (IS_ERR(shmem))
+ return ERR_CAST(shmem);
+
+ obj = __vgem_gem_create(dev, shmem, size);
+ if (IS_ERR(obj)) {
+ fput(shmem);
return ERR_CAST(obj);
+ }
ret = drm_gem_handle_create(file, &obj->base, handle);
if (ret) {
@@ -363,7 +370,7 @@ static struct drm_gem_object
*vgem_prime_import_sg_table(struct drm_device *dev,
struct drm_vgem_gem_object *obj;
int npages;
- obj = __vgem_gem_create(dev, attach->dmabuf->size);
+ obj = __vgem_gem_create(dev, NULL, attach->dmabuf->size);
if (IS_ERR(obj))
return ERR_CAST(obj);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset()
drm_gem_dumb_map_offset() now exists and does everything
vgem_gem_dump_map does and *ought* to do.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/vgem/vgem_drv.c | 28 +---
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index eb3b7cdac941..866cff537f28 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -236,32 +236,6 @@ static int vgem_gem_dumb_create(struct drm_file *file,
struct drm_device *dev,
return 0;
}
-static int vgem_gem_dumb_map(struct drm_file *file, struct drm_device *dev,
-uint32_t handle, uint64_t *offset)
-{
- struct drm_gem_object *obj;
- int ret;
-
- obj = drm_gem_object_lookup(file, handle);
- if (!obj)
- return -ENOENT;
-
- if (!obj->filp) {
- ret = -EINVAL;
- goto unref;
- }
-
- ret = drm_gem_create_mmap_offset(obj);
- if (ret)
- goto unref;
-
- *offset = drm_vma_node_offset_addr(&obj->vma_node);
-unref:
- drm_gem_object_put_unlocked(obj);
-
- return ret;
-}
-
static struct drm_ioctl_desc vgem_ioctls[] = {
DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl,
DRM_RENDER_ALLOW),
@@ -455,7 +429,7 @@ static struct drm_driver vgem_driver = {
.fops = &vgem_driver_fops,
.dumb_create= vgem_gem_dumb_create,
- .dumb_map_offset= vgem_gem_dumb_map,
+ .dumb_map_offset= drm_gem_dumb_map_offset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Unpin idle contexts from kswapd reclaim
We removed retiring requests from the shrinker in order to decouple the
mutexes from reclaim in preparation for unravelling the struct_mutex.
The impact of not retiring is that we are much less agressive in making
global objects available for shrinking, as such objects remain pinned
until they are flushed by a heartbeat pulse following the last retired
request along their timeline. In order to ensure that pulse occurs in
time for memory reclamation, we should kick it from kswapd.
The catch is that we have added some flush_work() into the retirement
phase (to ensure that we reach a global idle in a timely manner), but
these flush_work() are not eligible (i.e do not belong to WQ_MEM_RELCAIM)
for use from inside kswapd. To avoid flushing those workqueues, we teach
the retirer not to do so unless we are actually waiting, and only do the
plain retire from inside the shrinker.
Note that for execlists, we already retire completed contexts as they
are scheduled out, so it should not be keeping global state
unnecessarily pinned. The legacy ringbuffer however...
References: 9e9539800dd4 ("drm/i915: Remove waiting & retiring from shrinker
paths")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 25 +---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 9 ---
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 1ced1e5d2ec0..dc8f052a0ffe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -13,6 +13,8 @@
#include
#include
+#include "gt/intel_gt_requests.h"
+
#include "i915_trace.h"
static bool swap_available(void)
@@ -111,15 +113,6 @@ i915_gem_shrink(struct drm_i915_private *i915,
unsigned long count = 0;
unsigned long scanned = 0;
- /*
-* When shrinking the active list, we should also consider active
-* contexts. Active contexts are pinned until they are retired, and
-* so can not be simply unbound to retire and unpin their pages. To
-* shrink the contexts, we must wait until the gpu is idle and
-* completed its switch to the kernel context. In short, we do
-* not have a good mechanism for idling a specific context.
-*/
-
trace_i915_gem_shrink(i915, target, shrink);
/*
@@ -133,6 +126,20 @@ i915_gem_shrink(struct drm_i915_private *i915,
shrink &= ~I915_SHRINK_BOUND;
}
+ /*
+* When shrinking the active list, we should also consider active
+* contexts. Active contexts are pinned until they are retired, and
+* so can not be simply unbound to retire and unpin their pages. To
+* shrink the contexts, we must wait until the gpu is idle and
+* completed its switch to the kernel context. In short, we do
+* not have a good mechanism for idling a specific context, but
+* what we can do is give them a kick so that we do not keep idle
+* contexts around longer than is necessary.
+*/
+ if (shrink & I915_SHRINK_ACTIVE)
+ /* Retire requests to unpin all idle contexts */
+ intel_gt_retire_requests(&i915->gt);
+
/*
* As we may completely rewrite the (un)bound list whilst unbinding
* (due to retiring requests) we have to strictly process only
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 16ff47c83bd5..66fcbf9d0fdd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -31,12 +31,15 @@ static bool engine_active(const struct intel_engine_cs
*engine)
return !list_empty(&engine->kernel_context->timeline->requests);
}
-static bool flush_submission(struct intel_gt *gt)
+static bool flush_submission(struct intel_gt *gt, long timeout)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
bool active = false;
+ if (!timeout)
+ return false;
+
if (!intel_gt_pm_is_awake(gt))
return false;
@@ -139,7 +142,7 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout)
if (unlikely(timeout < 0))
timeout = -timeout, interruptible = false;
- flush_submission(gt); /* kick the ksoftirqd tasklets */
+ flush_submission(gt, timeout); /* kick the ksoftirqd tasklets */
spin_lock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &timelines->active_list, link) {
if (!mutex_trylock(&tl->mutex)) {
@@ -194,7 +197,7 @@ out_active: spin_lock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &free, link)
__intel_timeline_free(&tl->kref);
- if (flush_submission(gt)) /* Wait, there's more! */
+ if (flush_submission(gt, timeout)) /* Wait, there'
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
== Series Details == Series: series starting with [1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object URL : https://patchwork.freedesktop.org/series/79203/ State : failure == Summary == Applying: drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object Applying: drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset() error: sha1 information is lacking or useless (drivers/gpu/drm/vgem/vgem_drv.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0002 drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset() When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Unpin idle contexts from kswapd reclaim
== Series Details ==
Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79204/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9357a85637f9 drm/i915/gem: Unpin idle contexts from kswapd reclaim
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#25:
References: 9e9539800dd4 ("drm/i915: Remove waiting & retiring from shrinker
paths")
-:25: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 9e9539800dd4 ("drm/i915: Remove
waiting & retiring from shrinker paths")'
#25:
References: 9e9539800dd4 ("drm/i915: Remove waiting & retiring from shrinker
paths")
total: 1 errors, 1 warnings, 0 checks, 75 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Unpin idle contexts from kswapd reclaim
== Series Details ==
Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79204/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18096
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/index.html
Known issues
Here are the changes found in Patchwork_18096 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_addfb_basic@bad-pitch-32:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@kms_addfb_ba...@bad-pitch-32.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-tgl-y/igt@kms_addfb_ba...@bad-pitch-32.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][5] ([i915#95]) -> [PASS][6] +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-tgl-dsi}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-apl-guc: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@mmap:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@vgem_ba...@mmap.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-tgl-y/igt@vgem_ba...@mmap.html
Warnings
* igt@kms_flip@basic-plain-flip@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (42 -> 35)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-tgl-u2 fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8710 -> Patchwork_18096
CI-20190529: 20190529
CI_DR
[Intel-gfx] [PATCH] drm/i915/display: Fix initial fb to use resource_size_t
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits within a plain u32 [based
on prior assumptions that we were simpling handling offsets into the
GGTT not physical memory].
We made the switch to using resource_size_t for stolen in commit
b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
Reported-by: Tvrtko Ursulin
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dff7c17f3d2b..6bfe3148f927 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3409,7 +3409,8 @@ initial_plane_vma(struct drm_i915_private *i915,
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- u32 base, size;
+ resource_size_t base;
+ resource_size_t size;
if (plane_config->size == 0)
return NULL;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
Quoting lepton (2020-07-07 18:05:21) > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote: > > > > If we assign obj->filp, we believe that the create vgem bo is native and > > allow direct operations like mmap() assuming it behaves as backed by a > > shmemfs inode. When imported from a dmabuf, the obj->pages are > > not always meaningful and the shmemfs backing store misleading. > > > > Note, that regular mmap access to a vgem bo is via the dumb buffer API, > > and that rejects attempts to mmap an imported dmabuf, > What do you mean by "regular mmap access" here? It looks like vgem is > using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call > drm_gem_dumb_map_offset As I too found out, and so had to correct my story telling. By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer API] as opposed to mmap() via an exported dma-buf fd. I had to look at igt to see how it was being used. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value
Hi, On 7/7/20 9:34 AM, Uwe Kleine-König wrote: On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: Hi, Thank you for your review and sorry for the slow reply. No problem for me, I didn't hold my breath :-) diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c index 43b1fc634af1..80d0f9c64f9d 100644 --- a/drivers/pwm/pwm-lpss.c +++ b/drivers/pwm/pwm-lpss.c @@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm, freq *= base_unit_range; base_unit = DIV_ROUND_CLOSEST_ULL(freq, c); DIV_ROUND_CLOSEST_ULL is most probably wrong, too. But I didn't spend the time to actually confirm that. Yes I saw your comment elsewhere that the PWM API defines rounding in a certain direction, but fixing that falls outside of this patch. Yeah, sure. [...] I hope this helps to explain what is going on a bit. I will try to make sense of that and reply to the patch directly when I succeeded. ### As for the behavior on base_unit==0 in the get_state method, as mentioned above I wrote that when I did not fully understood how the controller works. We really should never encounter this. But if we do then I think closest to the truth would be: state->period = UINT_MAX; state->duty_cycle = 0; I'd say state->period = 1 & state->duty_cycle = 0 is a better representation. But that would suggest the output is configured for an infinitely high output frequency, but the frequency is actually 0, the reason why get_state needs to treat a base_unit val of 0 special at all is to avoid a division by 0, and in math dividing by 0 gives infinite, isn't UINT_MAX a better way to represent infinity ? Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson wrote:
>
> If we assign obj->filp, we believe that the create vgem bo is native and
> allow direct operations like mmap() assuming it behaves as backed by a
> shmemfs inode. When imported from a dmabuf, the obj->pages are
> not always meaningful and the shmemfs backing store misleading.
>
> Note, that regular mmap access to a vgem bo is via the dumb buffer API,
> and that rejects attempts to mmap an imported dmabuf,
What do you mean by "regular mmap access" here? It looks like vgem is
using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call
drm_gem_dumb_map_offset
>
> drm_gem_dumb_map_offset():
> if (obj->import_attach) return -EINVAL;
>
> So the only route by which we might accidentally allow mmapping of an
> imported buffer is via vgem_prime_mmap(), which checked for
> obj->filp assuming that it would be NULL.
>
> Well it would had it been updated to use the common
> drm_gem_dum_map_offset() helper, instead it has
>
> vgem_gem_dumb_map():
> if (!obj->filp) return -EINVAL;
>
> falling foul of the same trap as above.
>
> Reported-by: Lepton Wu
> Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
> Signed-off-by: Chris Wilson
> Cc: Lepton Wu
> Cc: Daniel Vetter
> Cc: Christian König
> Cc: Thomas Hellström (Intel)
> Cc: # v4.13+
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 27 +--
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 909eba43664a..eb3b7cdac941 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -91,7 +91,7 @@ static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> ret = 0;
> }
> mutex_unlock(&obj->pages_lock);
> - if (ret) {
> + if (ret && obj->base.filp) {
> struct page *page;
>
> page = shmem_read_mapping_page(
> @@ -157,7 +157,8 @@ static void vgem_postclose(struct drm_device *dev, struct
> drm_file *file)
> }
>
> static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
> - unsigned long size)
> +struct file *shmem,
> +unsigned long size)
> {
> struct drm_vgem_gem_object *obj;
> int ret;
> @@ -166,11 +167,8 @@ static struct drm_vgem_gem_object
> *__vgem_gem_create(struct drm_device *dev,
> if (!obj)
> return ERR_PTR(-ENOMEM);
>
> - ret = drm_gem_object_init(dev, &obj->base, roundup(size, PAGE_SIZE));
> - if (ret) {
> - kfree(obj);
> - return ERR_PTR(ret);
> - }
> + drm_gem_private_object_init(dev, &obj->base, size);
> + obj->base.filp = shmem;
>
> mutex_init(&obj->pages_lock);
>
> @@ -189,11 +187,20 @@ static struct drm_gem_object *vgem_gem_create(struct
> drm_device *dev,
> unsigned long size)
> {
> struct drm_vgem_gem_object *obj;
> + struct file *shmem;
> int ret;
>
> - obj = __vgem_gem_create(dev, size);
> - if (IS_ERR(obj))
> + size = roundup(size, PAGE_SIZE);
> +
> + shmem = shmem_file_setup(DRIVER_NAME, size, VM_NORESERVE);
> + if (IS_ERR(shmem))
> + return ERR_CAST(shmem);
> +
> + obj = __vgem_gem_create(dev, shmem, size);
> + if (IS_ERR(obj)) {
> + fput(shmem);
> return ERR_CAST(obj);
> + }
>
> ret = drm_gem_handle_create(file, &obj->base, handle);
> if (ret) {
> @@ -363,7 +370,7 @@ static struct drm_gem_object
> *vgem_prime_import_sg_table(struct drm_device *dev,
> struct drm_vgem_gem_object *obj;
> int npages;
>
> - obj = __vgem_gem_create(dev, attach->dmabuf->size);
> + obj = __vgem_gem_create(dev, NULL, attach->dmabuf->size);
> if (IS_ERR(obj))
> return ERR_CAST(obj);
>
> --
> 2.27.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Fix initial fb to use resource_size_t
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t
URL : https://patchwork.freedesktop.org/series/79205/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f694486df0d8 drm/i915/display: Fix initial fb to use resource_size_t
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b7128ef125b4 ("drm/i915: prefer
resource_size_t for everything stolen")'
#17:
b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#20:
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b7128ef125b4 ("drm/i915: prefer
resource_size_t for everything stolen")'
#20:
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
total: 2 errors, 1 warnings, 0 checks, 9 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix initial fb to use resource_size_t
On 07/07/2020 18:15, Chris Wilson wrote:
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits within a plain u32 [based
on prior assumptions that we were simpling handling offsets into the
GGTT not physical memory].
We made the switch to using resource_size_t for stolen in commit
b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
Reported-by: Tvrtko Ursulin
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dff7c17f3d2b..6bfe3148f927 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3409,7 +3409,8 @@ initial_plane_vma(struct drm_i915_private *i915,
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- u32 base, size;
+ resource_size_t base;
+ resource_size_t size;
if (plane_config->size == 0)
return NULL;
There is also:
base = round_down(plane_config->base,
I915_GTT_MIN_ALIGNMENT);
struct intel_initial_plane_config {
struct intel_framebuffer *fb;
struct i915_vma *vma;
unsigned int tiling;
int size;
u32 base;
u8 rotation;
};
So not sure, just throwing it out there.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix initial fb to use resource_size_t
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18097
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/index.html
Known issues
Here are the changes found in Patchwork_18097 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-byt-j1900/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-tgl-u2: [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-u2/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][9] ([i915#95]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [INCOMPLETE][11] ([i915#2089] / [i915#750]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-apl-guc: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@mmap:
- fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@vgem_ba...@mmap.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-tgl-y/igt@vgem_ba...@mmap.html
Warnings
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +1 similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the statu
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix initial fb to use resource_size_t
Quoting Tvrtko Ursulin (2020-07-07 18:48:23)
>
> On 07/07/2020 18:15, Chris Wilson wrote:
> > We lookup up the physical address of the inherited framebuffer, and
> > presume that is an offset into the stolen memory region. As we are
> > dealing with physical resources and their addresses, we need to use
> > resource_size_t and not assume everything fits within a plain u32 [based
> > on prior assumptions that we were simpling handling offsets into the
> > GGTT not physical memory].
> >
> > We made the switch to using resource_size_t for stolen in commit
> > b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
> >
> > Reported-by: Tvrtko Ursulin
> > References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
> > stolen")
> > Signed-off-by: Chris Wilson
> > Cc: Ville Syrjälä
> > Cc: Tvrtko Ursulin
> > Cc: Matthew Auld
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index dff7c17f3d2b..6bfe3148f927 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -3409,7 +3409,8 @@ initial_plane_vma(struct drm_i915_private *i915,
> > {
> > struct drm_i915_gem_object *obj;
> > struct i915_vma *vma;
> > - u32 base, size;
> > + resource_size_t base;
> > + resource_size_t size;
> >
> > if (plane_config->size == 0)
> > return NULL;
> >
>
> There is also:
>
> base = round_down(plane_config->base,
> I915_GTT_MIN_ALIGNMENT);
>
> struct intel_initial_plane_config {
> struct intel_framebuffer *fb;
> struct i915_vma *vma;
> unsigned int tiling;
> int size;
> u32 base;
> u8 rotation;
> };
>
> So not sure, just throwing it out there.
In for a penny, in for a pound.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/display: Fix initial fb to use resource_size_t
We lookup up the physical address of the inherited framebuffer, and
presume that is an offset into the stolen memory region. As we are
dealing with physical resources and their addresses, we need to use
resource_size_t and not assume everything fits within a plain u32 [based
on prior assumptions that we were simply handling offsets into the
GGTT not generic addresses/offsets].
We made the switch to using resource_size_t for stolen in commit
b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
v2: Expand the intel_initial_plane_config struct as well to accommodate
any possible location.
Reported-by: Tvrtko Ursulin
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_display.c | 15 ---
.../gpu/drm/i915/display/intel_display_types.h| 4 ++--
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dff7c17f3d2b..9fd18b3dbb37 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3409,7 +3409,8 @@ initial_plane_vma(struct drm_i915_private *i915,
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- u32 base, size;
+ resource_size_t base;
+ resource_size_t size;
if (plane_config->size == 0)
return NULL;
@@ -9319,13 +9320,13 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
aligned_height = intel_fb_align_height(fb, 0, fb->height);
- plane_config->size = fb->pitches[0] * aligned_height;
+ plane_config->size = mul_u32_u32(fb->pitches[0], aligned_height);
drm_dbg_kms(&dev_priv->drm,
- "%s/%s with fb: size=%dx%d@%d, offset=%x, pitch %d, size
0x%x\n",
+ "%s/%s with fb: size=%dx%d@%d, offset=%x, pitch %d, size
0x%pa\n",
crtc->base.name, plane->base.name, fb->width, fb->height,
fb->format->cpp[0] * 8, base, fb->pitches[0],
- plane_config->size);
+ &plane_config->size);
plane_config->fb = intel_fb;
}
@@ -10595,13 +10596,13 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
aligned_height = intel_fb_align_height(fb, 0, fb->height);
- plane_config->size = fb->pitches[0] * aligned_height;
+ plane_config->size = mul_u32_u32(fb->pitches[0], aligned_height);
drm_dbg_kms(&dev_priv->drm,
- "%s/%s with fb: size=%dx%d@%d, offset=%x, pitch %d, size
0x%x\n",
+ "%s/%s with fb: size=%dx%d@%d, offset=%x, pitch %d, size
0x%pa\n",
crtc->base.name, plane->base.name, fb->width, fb->height,
fb->format->cpp[0] * 8, base, fb->pitches[0],
- plane_config->size);
+ &plane_config->size);
plane_config->fb = intel_fb;
return;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e8f809161c75..75cbf00f5c9b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -591,9 +591,9 @@ struct intel_plane_state {
struct intel_initial_plane_config {
struct intel_framebuffer *fb;
struct i915_vma *vma;
+ resource_size_t base;
+ resource_size_t size;
unsigned int tiling;
- int size;
- u32 base;
u8 rotation;
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Fix initial fb to use resource_size_t (rev2)
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2)
URL : https://patchwork.freedesktop.org/series/79205/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
40ee693823d1 drm/i915/display: Fix initial fb to use resource_size_t
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b7128ef125b4 ("drm/i915: prefer
resource_size_t for everything stolen")'
#17:
b7128ef125b4 ("drm/i915: prefer resource_size_t for everything stolen")
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#23:
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b7128ef125b4 ("drm/i915: prefer
resource_size_t for everything stolen")'
#23:
References: b7128ef125b4 ("drm/i915: prefer resource_size_t for everything
stolen")
total: 2 errors, 1 warnings, 0 checks, 52 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote: > > Quoting lepton (2020-07-07 18:05:21) > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson > > wrote: > > > > > > If we assign obj->filp, we believe that the create vgem bo is native and > > > allow direct operations like mmap() assuming it behaves as backed by a > > > shmemfs inode. When imported from a dmabuf, the obj->pages are > > > not always meaningful and the shmemfs backing store misleading. > > > > > > Note, that regular mmap access to a vgem bo is via the dumb buffer API, > > > and that rejects attempts to mmap an imported dmabuf, > > What do you mean by "regular mmap access" here? It looks like vgem is > > using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call > > drm_gem_dumb_map_offset > > As I too found out, and so had to correct my story telling. > > By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer > API] as opposed to mmap() via an exported dma-buf fd. I had to look at > igt to see how it was being used. Now it seems your fix is to disable "regular mmap" on imported dma buf for vgem. I am not really a graphic guy, but then the api looks like: for a gem handle, user space has to guess to find out the way to mmap it. If user space guess wrong, then it will fail to mmap. Is this the expected way for people to handle gpu buffer? > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object
Quoting lepton (2020-07-07 19:17:51) > On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote: > > > > Quoting lepton (2020-07-07 18:05:21) > > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson > > > wrote: > > > > > > > > If we assign obj->filp, we believe that the create vgem bo is native and > > > > allow direct operations like mmap() assuming it behaves as backed by a > > > > shmemfs inode. When imported from a dmabuf, the obj->pages are > > > > not always meaningful and the shmemfs backing store misleading. > > > > > > > > Note, that regular mmap access to a vgem bo is via the dumb buffer API, > > > > and that rejects attempts to mmap an imported dmabuf, > > > What do you mean by "regular mmap access" here? It looks like vgem is > > > using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call > > > drm_gem_dumb_map_offset > > > > As I too found out, and so had to correct my story telling. > > > > By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer > > API] as opposed to mmap() via an exported dma-buf fd. I had to look at > > igt to see how it was being used. > Now it seems your fix is to disable "regular mmap" on imported dma buf > for vgem. I am not really a graphic guy, but then the api looks like: > for a gem handle, user space has to guess to find out the way to mmap > it. If user space guess wrong, then it will fail to mmap. Is this the > expected way > for people to handle gpu buffer? You either have a dumb buffer handle, or a dma-buf fd. If you have the handle, you have to use the dumb buffer API, there's no other way to mmap it. If you have the dma-buf fd, you should mmap it directly. Those two are clear. It's when you import the dma-buf into vgem and create a handle out of it, that's when the handle is no longer first class and certain uAPI [the dumb buffer API in particular] fail. It's not brilliant, as you say, it requires the user to remember the difference between the handles, but at the same time it does prevent them falling into coherency traps by forcing them to use the right driver to handle the object, and have to consider the additional ioctls that go along with that access. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix initial fb to use resource_size_t (rev2)
== Series Details ==
Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2)
URL : https://patchwork.freedesktop.org/series/79205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8710 -> Patchwork_18098
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/index.html
Known issues
Here are the changes found in Patchwork_18098 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_store@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@gem_exec_st...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-tgl-y/igt@gem_exec_st...@basic.html
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@kms_busy@basic@flip:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-tgl-y/igt@kms_busy@ba...@flip.html
Possible fixes
* igt@gem_render_linear_blits@basic:
- fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-tgl-y/igt@gem_render_linear_bl...@basic.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-byt-j1900/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-whl-u: [DMESG-WARN][11] ([i915#95]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@execlists:
- {fi-tgl-dsi}: [INCOMPLETE][13] ([i915#2089] / [i915#750]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-tgl-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-apl-guc: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-apl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +6 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2089]: https://gitlab.freedesktop.org/drm/intel/issues/2089
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#750]: https://gitlab.freedesktop.
Re: [Intel-gfx] [PATCH v3 15/15] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller
Hi Uwe,
On 7/7/20 9:50 AM, Uwe Kleine-König wrote:
Hello Hans,
On Sat, Jun 20, 2020 at 02:17:58PM +0200, Hans de Goede wrote:
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
Note that there is no hard dependency, the atomic API should work just
fine even with a non-converted driver. (Of course a converted driver
behaves better, but the i915 using the atomic API with a non-converted
driver is just as good as the legacy API with the same driver.)
So regarding your plan to get this series in soon: There is no hard need
to halt the efforts for the drm part if the pwm patches take a bit
longer (or vice versa).
I understand, but the main reason to do the conversion to the atomic
API, is to be able to skip the step where we force the backlight
to 100% brightness (which can look quite ugly during boot).
After this patch the intel-panel code initializes its internal
backlight state and the brightness reported under /sys/class/backlight
with the "brightness" returned from the PWM-drivers' get_state callback.
Without getting the PWM patches in first I think that things will
mostly work, but we will always report an initial brightness value
of 0. Lets say it is actually 50% and the user then presses the
increase-brightness hotkey, causing userspace to change it from 0% to 5%
so instead of increasing it by 1/20th, it just decreased it a lot.
So I do believe it is better to get the whole series in as a whole,
since we are at rc4 already (time flies) I guess it might not make it
in this cycle, but that is fine.
Talking about merging this, is it ok for me to push the entire
series upstream through the intel-drm-next-queued branch,
once all the PWM patches have your Ack?
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastset path.
Signed-off-by: Hans de Goede
---
.../drm/i915/display/intel_display_types.h| 3 +-
drivers/gpu/drm/i915/display/intel_panel.c| 73 +--
2 files changed, 37 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index de32f9efb120..4bd9981e70a1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -223,7 +224,7 @@ struct intel_panel {
bool util_pin_active_low; /* bxt+ */
u8 controller; /* bxt+ only */
struct pwm_device *pwm;
- int pwm_period_ns;
+ struct pwm_state pwm_state;
/* DPCD backlight */
u8 pwmgen_bit_count;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index cb28b9908ca4..a0f76343f381 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -592,10 +592,11 @@ static u32 bxt_get_backlight(struct intel_connector
*connector)
static u32 pwm_get_backlight(struct intel_connector *connector)
{
struct intel_panel *panel = &connector->panel;
- int duty_ns;
+ int duty_ns, period_ns;
duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
- return DIV_ROUND_UP(duty_ns * 100, panel->backlight.pwm_period_ns);
+ period_ns = pwm_get_period(panel->backlight.pwm);
The transformation is correct, but using
pwm_get_state(pwm, &state);
duty_ns = state.duty_cycle;
period_ns = state.period;
is a bit more effective as it calls pwm_get_state() only once.
There is a function pwm_get_relative_duty_cycle which is similar (with
scale = 100) just used different rounding.
Ah nice, that is better then doing our own stuff.
I will switch to that for v4 of this patch-set.
+ return DIV_ROUND_UP(duty_ns * 100, period_ns);
}
static void lpt_set_backlight(const struct drm_connector_state *conn_state, u32 level)
@@ -669,10 +670,10 @@ static void bxt_set_backlight(const struct
drm_connector_state *conn_state, u32
static void pwm_set_backlight(const struct drm_connector_state *conn_state,
u32 level)
{
struct intel_panel *panel =
&to_intel_connector(conn_state->connector)->panel;
- int duty_ns = DIV_ROUND_UP(level * panel->backlight.pwm_period_ns, 100);
- pwm_config(panel->backlight.pwm, duty_ns,
- panel->backlight.pwm_period_ns);
+ panel->backlight.pwm_state.duty_cycle =
+ DIV_ROUND_UP(level * panel->backlight.pwm_state.period, 100);
+ pwm_apply_state(panel->backlight.pwm, &panel->backlight.pwm_state);
}
static void
@@ -841,10 +842,8 @@ static void pwm_disable_backlight(const struct
drm_connector_state *old_conn_sta
struct intel_connector *connector =
to_int
Re: [Intel-gfx] [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value
Hi, On 7/7/20 9:09 PM, Uwe Kleine-König wrote: Hello Hans, On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote: On 7/7/20 9:34 AM, Uwe Kleine-König wrote: On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: But if we do then I think closest to the truth would be: state->period = UINT_MAX; state->duty_cycle = 0; I'd say state->period = 1 & state->duty_cycle = 0 is a better representation. But that would suggest the output is configured for an infinitely high output frequency, but the frequency is actually 0, the reason why get_state needs to treat a base_unit val of 0 special at all is to avoid a division by 0, and in math dividing by 0 gives infinite, isn't UINT_MAX a better way to represent infinity ? Given that duty_cycle is 0, how can to tell anything about the period when only seeing the signal (= a constant low)? Given that (ideally) a period is completed when pwm_apply_state() is called, a short period is much more sensible. Ok, I will add a patch to v4 of the patch-set to adjust the pwm-lpss driver's get_state method accordingly. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Remove i915_gem_object_get_dirty_page()
Last user removed, remove the convenience function.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 --
2 files changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index f9f91ec09a2f..a2d6a83d4d55 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -258,10 +258,6 @@ struct page *
i915_gem_object_get_page(struct drm_i915_gem_object *obj,
unsigned int n);
-struct page *
-i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj,
- unsigned int n);
-
dma_addr_t
i915_gem_object_get_dma_address_len(struct drm_i915_gem_object *obj,
unsigned long n,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 114256014a97..5aa9f584b154 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -553,20 +553,6 @@ i915_gem_object_get_page(struct drm_i915_gem_object *obj,
unsigned int n)
return nth_page(sg_page(sg), offset);
}
-/* Like i915_gem_object_get_page(), but mark the returned page dirty */
-struct page *
-i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj,
- unsigned int n)
-{
- struct page *page;
-
- page = i915_gem_object_get_page(obj, n);
- if (!obj->mm.dirty)
- set_page_dirty(page);
-
- return page;
-}
-
dma_addr_t
i915_gem_object_get_dma_address_len(struct drm_i915_gem_object *obj,
unsigned long n,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Release shortlived maps of longlived objects
Some objects we map once during their construction, and then never
access their mappings again, even if they are kept around for the
duration of the driver. Keeping those pages mapped, often vmapped, is
therefore wasteful and we should release the maps as soon as we no
longer need them.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 20 +++
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
.../gpu/drm/i915/gt/intel_ring_submission.c | 1 +
drivers/gpu/drm/i915/i915_perf.c | 2 ++
6 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 2faa481cc18f..f9f91ec09a2f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -393,6 +393,7 @@ static inline void i915_gem_object_unpin_map(struct
drm_i915_gem_object *obj)
{
i915_gem_object_unpin_pages(obj);
}
+int i915_gem_object_release_map(struct drm_i915_gem_object *obj);
void
i915_gem_object_flush_write_domain(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index af9e48ee4a33..114256014a97 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -408,6 +408,26 @@ void __i915_gem_object_flush_map(struct
drm_i915_gem_object *obj,
}
}
+int i915_gem_object_release_map(struct drm_i915_gem_object *obj)
+{
+ int err;
+
+ err = mutex_lock_interruptible(&obj->mm.lock);
+ if (err)
+ return err;
+
+ if (atomic_read(&obj->mm.pages_pin_count)) {
+ err = -EBUSY;
+ } else if (obj->mm.mapping) {
+ unmap_object(obj, page_mask_bits(obj->mm.mapping));
+ obj->mm.mapping = NULL;
+ }
+
+ mutex_unlock(&obj->mm.lock);
+
+ return err;
+}
+
struct scatterlist *
i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
unsigned int n,
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
index de595b66a746..d2a94002ae6e 100644
--- a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -397,6 +397,7 @@ int gen7_setup_clear_gpr_bb(struct intel_engine_cs * const
engine,
i915_gem_object_flush_map(vma->obj);
i915_gem_object_unpin_map(vma->obj);
+ i915_gem_object_release_map(vma->obj);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 02a38810bcd3..476dfc6be15e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3938,6 +3938,7 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
__i915_gem_object_flush_map(wa_ctx->vma->obj, 0, batch_ptr - batch);
i915_gem_object_unpin_map(wa_ctx->vma->obj);
+ i915_gem_object_release_map(wa_ctx->vma->obj);
if (ret)
lrc_destroy_wa_ctx(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 68a08486fc87..a1e1d24da2fb 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -544,6 +544,7 @@ alloc_context_vma(struct intel_engine_cs *engine)
i915_gem_object_flush_map(obj);
i915_gem_object_unpin_map(obj);
+ i915_gem_object_release_map(obj);
}
vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 25329b7600c9..34f82e0e912a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1773,6 +1773,7 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
i915_gem_object_flush_map(bo);
i915_gem_object_unpin_map(bo);
+ i915_gem_object_release_map(bo);
stream->noa_wait = vma;
return 0;
@@ -1868,6 +1869,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
i915_gem_object_flush_map(obj);
i915_gem_object_unpin_map(obj);
+ i915_gem_object_release_map(obj);
oa_bo->vma = i915_vma_instance(obj,
&stream->engine->gt->ggtt->vm,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/gt: Replace opencoded i915_gem_object_pin_map()
As we have a pin_map interface, that knows how to flush the data to the
device, use it. The only downside is that we keep the kmap around, as
once acquired we keep the mapping cached until the object's backing
store is released.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e866b8d721ed..02a38810bcd3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3880,7 +3880,6 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
struct i915_wa_ctx_bb *wa_bb[2] = { &wa_ctx->indirect_ctx,
&wa_ctx->per_ctx };
wa_bb_func_t wa_bb_fn[2];
- struct page *page;
void *batch, *batch_ptr;
unsigned int i;
int ret;
@@ -3916,14 +3915,14 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
return ret;
}
- page = i915_gem_object_get_dirty_page(wa_ctx->vma->obj, 0);
- batch = batch_ptr = kmap_atomic(page);
+ batch = i915_gem_object_pin_map(wa_ctx->vma->obj, I915_MAP_WB);
/*
* Emit the two workaround batch buffers, recording the offset from the
* start of the workaround batch buffer object for each and their
* respective sizes.
*/
+ batch_ptr = batch;
for (i = 0; i < ARRAY_SIZE(wa_bb_fn); i++) {
wa_bb[i]->offset = batch_ptr - batch;
if (GEM_DEBUG_WARN_ON(!IS_ALIGNED(wa_bb[i]->offset,
@@ -3935,10 +3934,10 @@ static int intel_init_workaround_bb(struct
intel_engine_cs *engine)
batch_ptr = wa_bb_fn[i](engine, batch_ptr);
wa_bb[i]->size = batch_ptr - (batch + wa_bb[i]->offset);
}
+ GEM_BUG_ON(batch_ptr - batch > CTX_WA_BB_OBJ_SIZE);
- BUG_ON(batch_ptr - batch > CTX_WA_BB_OBJ_SIZE);
-
- kunmap_atomic(batch);
+ __i915_gem_object_flush_map(wa_ctx->vma->obj, 0, batch_ptr - batch);
+ i915_gem_object_unpin_map(wa_ctx->vma->obj);
if (ret)
lrc_destroy_wa_ctx(engine);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/25] drm/vblank: Annotate with dma-fence signalling section
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_vblank.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 42a84eb4cc8c..d681ab09963c 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -24,6 +24,7 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
@@ -1909,7 +1910,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
{
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
unsigned long irqflags;
- bool disable_irq;
+ bool disable_irq, fence_cookie;
if (drm_WARN_ON_ONCE(dev, !drm_dev_has_vblank(dev)))
return false;
@@ -1917,6 +1918,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return false;
+ fence_cookie = dma_fence_begin_signalling();
+
spin_lock_irqsave(&dev->event_lock, irqflags);
/* Need timestamp lock to prevent concurrent execution with
@@ -1929,6 +1932,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (!vblank->enabled) {
spin_unlock(&dev->vblank_time_lock);
spin_unlock_irqrestore(&dev->event_lock, irqflags);
+ dma_fence_end_signalling(fence_cookie);
return false;
}
@@ -1954,6 +1958,8 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
if (disable_irq)
vblank_disable_fn(&vblank->disable_timer);
+ dma_fence_end_signalling(fence_cookie);
+
return true;
}
EXPORT_SYMBOL(drm_handle_vblank);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea
Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.
What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is allowed.
v2: Now with dot graph!
Cc: Jesse Natalie
Cc: Steve Pronovost
Cc: Jason Ekstrand
Cc: Felix Kuehling
Cc: Mika Kuoppala
Cc: Thomas Hellstrom
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/dma-buf.rst | 70
drivers/gpu/drm/virtio/virtgpu_display.c | 20 ---
2 files changed, 70 insertions(+), 20 deletions(-)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index f8f6decde359..037ba0078bb4 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -178,3 +178,73 @@ DMA Fence uABI/Sync File
.. kernel-doc:: include/linux/sync_file.h
:internal:
+Idefinite DMA Fences
+
+
+At various times &dma_fence with an indefinite time until dma_fence_wait()
+finishes have been proposed. Examples include:
+
+* Future fences, used in HWC1 to signal when a buffer isn't used by the display
+ any longer, and created with the screen update that makes the buffer visible.
+ The time this fence completes is entirely under userspace's control.
+
+* Proxy fences, proposed to handle &drm_syncobj for which the fence has not yet
+ been set. Used to asynchronously delay command submission.
+
+* Userspace fences or gpu futexes, fine-grained locking within a command buffer
+ that userspace uses for synchronization across engines or with the CPU, which
+ are then imported as a DMA fence for integration into existing winsys
+ protocols.
+
+* Long-running compute command buffers, while still using traditional end of
+ batch DMA fences for memory management instead of context preemption DMA
+ fences which get reattached when the compute job is rescheduled.
+
+Common to all these schemes is that userspace controls the dependencies of
these
+fences and controls when they fire. Mixing indefinite fences with normal
+in-kernel DMA fences does not work, even when a fallback timeout is included to
+protect against malicious userspace:
+
+* Only the kernel knows about all DMA fence dependencies, userspace is not
aware
+ of dependencies injected due to memory management or scheduler decisions.
+
+* Only userspace knows about all dependencies in indefinite fences and when
+ exactly they will complete, the kernel has no visibility.
+
+Furthermore the kernel has to be able to hold up userspace command submission
+for memory management needs, which means we must support indefinite fences
being
+dependent upon DMA fences. If the kernel also support indefinite fences in the
+kernel like a DMA fence, like any of the above proposal would, there is the
+potential for deadlocks.
+
+.. kernel-render:: DOT
+ :alt: Indefinite Fencing Dependency Cycle
+ :caption: Indefinite Fencing Dependency Cycle
+
+ digraph "Fencing Cycle" {
+ node [shape=box bgcolor=grey style=filled]
+ kernel [label="Kernel DMA Fences"]
+ userspace [label="userspace controlled fences"]
+ kernel -> userspace [label="memory management"]
+ userspace -> kernel [label="Future fence, fence proxy, ..."]
+
+ { rank=same; kernel userspace }
+ }
+
+This means that the kernel might accidentally create deadlocks
+through memory management dependencies which userspace is unaware of, which
+randomly hangs workloads until the timeout kicks in. Workloads, which from
+userspace's perspective, do not contain a deadlock. In such a mixed fencing
+architecture there is no single entity with knowledge of all dependencies.
+Thefore preventing such deadlocks from within the kernel is not possible.
+
+The only solution to avoid dependencies loops is by not allowing indefinite
+fences in the kernel. This means:
+
+* No future fences, proxy fences or userspace fences imported as DMA fences,
+ with or without a timeout.
+
+* No DMA fences that signal end of batchbuffer for command submission where
+ userspace is allowed to use userspace fencing or long running compute
+ workloads. This also means no implicit fencing for shared buffers in these
+ cases.
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index f3ce49c5a34c..af55b334be2f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
return &virtio_gpu_fb->base;
}
-static void vgdev_atomic_commit_tail(struct drm_atomic_state *state)
-{
- struct drm_de
[Intel-gfx] [PATCH 01/25] dma-fence: basic lockdep annotations
Design is similar to the lockdep annotations for workers, but with some twists: - We use a read-lock for the execution/worker/completion side, so that this explicit annotation can be more liberally sprinkled around. With read locks lockdep isn't going to complain if the read-side isn't nested the same way under all circumstances, so ABBA deadlocks are ok. Which they are, since this is an annotation only. - We're using non-recursive lockdep read lock mode, since in recursive read lock mode lockdep does not catch read side hazards. And we _very_ much want read side hazards to be caught. For full details of this limitation see commit e91498589746065e3ae95d9a00b068e525eec34f Author: Peter Zijlstra Date: Wed Aug 23 13:13:11 2017 +0200 locking/lockdep/selftests: Add mixed read-write ABBA tests - To allow nesting of the read-side explicit annotations we explicitly keep track of the nesting. lock_is_held() allows us to do that. - The wait-side annotation is a write lock, and entirely done within dma_fence_wait() for everyone by default. - To be able to freely annotate helper functions I want to make it ok to call dma_fence_begin/end_signalling from soft/hardirq context. First attempt was using the hardirq locking context for the write side in lockdep, but this forces all normal spinlocks nested within dma_fence_begin/end_signalling to be spinlocks. That bollocks. The approach now is to simple check in_atomic(), and for these cases entirely rely on the might_sleep() check in dma_fence_wait(). That will catch any wrong nesting against spinlocks from soft/hardirq contexts. The idea here is that every code path that's critical for eventually signalling a dma_fence should be annotated with dma_fence_begin/end_signalling. The annotation ideally starts right after a dma_fence is published (added to a dma_resv, exposed as a sync_file fd, attached to a drm_syncobj fd, or anything else that makes the dma_fence visible to other kernel threads), up to and including the dma_fence_wait(). Examples are irq handlers, the scheduler rt threads, the tail of execbuf (after the corresponding fences are visible), any workers that end up signalling dma_fences and really anything else. Not annotated should be code paths that only complete fences opportunistically as the gpu progresses, like e.g. shrinker/eviction code. The main class of deadlocks this is supposed to catch are: Thread A: mutex_lock(A); mutex_unlock(A); dma_fence_signal(); Thread B: mutex_lock(A); dma_fence_wait(); mutex_unlock(A); Thread B is blocked on A signalling the fence, but A never gets around to that because it cannot acquire the lock A. Note that dma_fence_wait() is allowed to be nested within dma_fence_begin/end_signalling sections. To allow this to happen the read lock needs to be upgraded to a write lock, which means that any other lock is acquired between the dma_fence_begin_signalling() call and the call to dma_fence_wait(), and still held, this will result in an immediate lockdep complaint. The only other option would be to not annotate such calls, defeating the point. Therefore these annotations cannot be sprinkled over the code entirely mindless to avoid false positives. Originally I hope that the cross-release lockdep extensions would alleviate the need for explicit annotations: https://lwn.net/Articles/709849/ But there's a few reasons why that's not an option: - It's not happening in upstream, since it got reverted due to too many false positives: commit e966eaeeb623f09975ef362c2866fae6f86844f9 Author: Ingo Molnar Date: Tue Dec 12 12:31:16 2017 +0100 locking/lockdep: Remove the cross-release locking checks This code (CONFIG_LOCKDEP_CROSSRELEASE=y and CONFIG_LOCKDEP_COMPLETIONS=y), while it found a number of old bugs initially, was also causing too many false positives that caused people to disable lockdep - which is arguably a worse overall outcome. - cross-release uses the complete() call to annotate the end of critical sections, for dma_fence that would be dma_fence_signal(). But we do not want all dma_fence_signal() calls to be treated as critical, since many are opportunistic cleanup of gpu requests. If these get stuck there's still the main completion interrupt and workers who can unblock everyone. Automatically annotating all dma_fence_signal() calls would hence cause false positives. - cross-release had some educated guesses for when a critical section starts, like fresh syscall or fresh work callback. This would again cause false positives without explicit annotations, since for dma_fence the critical sections only starts when we publish a fence. - Furthermore there can be cases where a thread never does a dma_fence_signal, but is still critical for reaching completion of fences. One example would be a schedule
[Intel-gfx] [PATCH 02/25] dma-fence: prime lockdep annotations
Two in one go: - it is allowed to call dma_fence_wait() while holding a dma_resv_lock(). This is fundamental to how eviction works with ttm, so required. - it is allowed to call dma_fence_wait() from memory reclaim contexts, specifically from shrinker callbacks (which i915 does), and from mmu notifier callbacks (which amdgpu does, and which i915 sometimes also does, and probably always should, but that's kinda a debate). Also for stuff like HMM we really need to be able to do this, or things get real dicey. Consequence is that any critical path necessary to get to a dma_fence_signal for a fence must never a) call dma_resv_lock nor b) allocate memory with GFP_KERNEL. Also by implication of dma_resv_lock(), no userspace faulting allowed. That's some supremely obnoxious limitations, which is why we need to sprinkle the right annotations to all relevant paths. The one big locking context we're leaving out here is mmu notifiers, added in commit 23b68395c7c78a764e8963fc15a7cfd318bf187f Author: Daniel Vetter Date: Mon Aug 26 22:14:21 2019 +0200 mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end that one covers a lot of other callsites, and it's also allowed to wait on dma-fences from mmu notifiers. But there's no ready-made functions exposed to prime this, so I've left it out for now. v2: Also track against mmu notifier context. v3: kerneldoc to spec the cross-driver contract. Note that currently i915 throws in a hard-coded 10s timeout on foreign fences (not sure why that was done, but it's there), which is why that rule is worded with SHOULD instead of MUST. Also some of the mmu_notifier/shrinker rules might surprise SoC drivers, I haven't fully audited them all. Which is infeasible anyway, we'll need to run them with lockdep and dma-fence annotations and see what goes boom. v4: A spelling fix from Mika v5: #ifdef for CONFIG_MMU_NOTIFIER. Reported by 0day. Unfortunately this means lockdep enforcement is slightly inconsistent, it won't spot GFP_NOIO and GFP_NOFS allocations in the wrong spot if CONFIG_MMU_NOTIFIER is disabled in the kernel config. Oh well. v5: Note that only drivers/gpu has a reasonable (or at least historical) excuse to use dma_fence_wait() from shrinker and mmu notifier callbacks. Everyone else should either have a better memory manager model, or better hardware. This reflects discussions with Jason Gunthorpe. Cc: Jason Gunthorpe Cc: Felix Kuehling Cc: kernel test robot Reviewed-by: Thomas Hellström (v4) Cc: Mika Kuoppala Cc: Thomas Hellstrom Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- Documentation/driver-api/dma-buf.rst | 6 drivers/dma-buf/dma-fence.c | 46 drivers/dma-buf/dma-resv.c | 8 + include/linux/dma-fence.h| 1 + 4 files changed, 61 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 05d856131140..f8f6decde359 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -133,6 +133,12 @@ DMA Fences .. kernel-doc:: drivers/dma-buf/dma-fence.c :doc: DMA fences overview +DMA Fence Cross-Driver Contract +~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :doc: fence cross-driver contract + DMA Fence Signalling Annotations diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 0005bc002529..af1d8ea926b3 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -64,6 +64,52 @@ static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1); * &dma_buf.resv pointer. */ +/** + * DOC: fence cross-driver contract + * + * Since &dma_fence provide a cross driver contract, all drivers must follow the + * same rules: + * + * * Fences must complete in a reasonable time. Fences which represent kernels + * and shaders submitted by userspace, which could run forever, must be backed + * up by timeout and gpu hang recovery code. Minimally that code must prevent + * further command submission and force complete all in-flight fences, e.g. + * when the driver or hardware do not support gpu reset, or if the gpu reset + * failed for some reason. Ideally the driver supports gpu recovery which only + * affects the offending userspace context, and no other userspace + * submissions. + * + * * Drivers may have different ideas of what completion within a reasonable + * time means. Some hang recovery code uses a fixed timeout, others a mix + * between observing forward progress and increasingly strict timeouts. + * Drivers should not try to second guess timeout handling of fences from + * other drivers. + * + * * To ensure there's
[Intel-gfx] [PATCH 00/25] dma-fence annotations, round 3
Hi all, Bunch of changes that might matter: - Clarification that dma_fences are for drivers/gpu, requested by Jason Gunthorpe. - New patch to list all the past discussions around indefinite/future/whatever fences, and why this (sadly) still just plain doesn't work. Came up again when discussing this stuff, I'd like to just be able to point at some doc going forward. - I rolled dma-fence critical section annotations to (almost, vc4, nouveau and i915 have a bit too much custom commit functions) atomic kms drivers. Really looking for some serious testing with these, aside from the amdgpu atomic commit issues we've also found some problems in vmwgfx commit code. All real issues, and noted in the patches. After the modeset stuff there's still the drm/scheduler annotations. Testing with other drivers than amdgpu using the drm scheduler would be very much welcome. Then the usual pile of amdgpu hacks that I used for developing this. That stuff isn't for merging, I'm hoping amd is working on proper patches for these things. Testing for this series means, especially for the atomic kms drivers: - build with CONFIG_PROVE_LOCKING - run the kms_atomic igt, that one actually uses atomic in&out fences - withotu these it's only half the fun - run anything else you feel like which might use fences, like your rendering driver. You do have testcases for that right :-) The mmu notifier annotation integration landed in -mm for a few days meanwhile, but I busted it pretty bad. That one needs more baking, I'm trying to figure out how to write unit tests for these annotations so I'm not blowing them up all the time. Also I think it'd be nice if we could start merging some of the earlier stuff maybe, that doest start to feel solid (at least to me). Review, commenst and testing on drivers as per above very much welcome. Thanks, Daniel Daniel Vetter (25): dma-fence: basic lockdep annotations dma-fence: prime lockdep annotations dma-buf.rst: Document why idenfinite fences are a bad idea drm/vkms: Annotate vblank timer drm/vblank: Annotate with dma-fence signalling section drm/amdgpu: add dma-fence annotations to atomic commit path drm/komdea: Annotate dma-fence critical section in commit path drm/malidp: Annotate dma-fence critical section in commit path drm/atmel: Use drm_atomic_helper_commit drm/imx: Annotate dma-fence critical section in commit path drm/omapdrm: Annotate dma-fence critical section in commit path drm/rcar-du: Annotate dma-fence critical section in commit path drm/tegra: Annotate dma-fence critical section in commit path drm/tidss: Annotate dma-fence critical section in commit path drm/tilcdc: Use standard drm_atomic_helper_commit drm/atomic-helper: Add dma-fence annotations drm/scheduler: use dma-fence annotations in main thread drm/amdgpu: use dma-fence annotations in cs_submit() drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code drm/amdgpu: DC also loves to allocate stuff where it shouldn't drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail drm/scheduler: use dma-fence annotations in tdr work drm/amdgpu: use dma-fence annotations for gpu reset code Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset" drm/amdgpu: gpu recovery does full modesets Documentation/driver-api/dma-buf.rst | 82 +++ drivers/dma-buf/dma-fence.c | 207 ++ drivers/dma-buf/dma-resv.c| 8 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 22 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 2 +- drivers/gpu/drm/amd/amdgpu/atom.c | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +- .../gpu/drm/arm/display/komeda/komeda_kms.c | 3 + drivers/gpu/drm/arm/malidp_drv.c | 3 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 96 +--- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 4 - drivers/gpu/drm/drm_atomic_helper.c | 16 ++ drivers/gpu/drm/drm_vblank.c | 8 +- drivers/gpu/drm/imx/imx-drm-core.c| 2 + drivers/gpu/drm/omapdrm/omap_drv.c| 9 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 + drivers/gpu/drm/scheduler/sched_main.c| 11 + drivers/gpu/drm/tegra/drm.c | 3 + drivers/gpu/drm/tidss/tidss_kms.c | 4 + drivers/gpu/drm/tilcdc/tilcdc_drv.c | 47 +--- drivers/gpu/drm/virtio/virtgpu_display.c | 20 -- drivers/gpu/drm/vkms/vkms_crtc.c | 8 +- include/linux/dma-fence.h | 13 ++ 27 files changed, 421 insertions(+), 182 deletions(-) -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org htt
[Intel-gfx] [PATCH 04/25] drm/vkms: Annotate vblank timer
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Daniel Vetter
---
drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..a53a40848a72 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
+#include
+
#include
#include
#include
@@ -14,7 +16,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
struct drm_crtc *crtc = &output->crtc;
struct vkms_crtc_state *state;
u64 ret_overrun;
- bool ret;
+ bool ret, fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
output->period_ns);
@@ -49,6 +53,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
DRM_DEBUG_DRIVER("Composer worker already queued\n");
}
+ dma_fence_end_signalling(fence_cookie);
+
return HRTIMER_RESTART;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/25] drm/tidss: Annotate dma-fence critical section in commit path
Ends right after hw_done(), totally standard case.
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_kms.c
b/drivers/gpu/drm/tidss/tidss_kms.c
index b6e61d6cf60f..556bc801b77c 100644
--- a/drivers/gpu/drm/tidss/tidss_kms.c
+++ b/drivers/gpu/drm/tidss/tidss_kms.c
@@ -4,6 +4,8 @@
* Author: Tomi Valkeinen
*/
+#include
+
#include
#include
#include
@@ -26,6 +28,7 @@ static void tidss_atomic_commit_tail(struct drm_atomic_state
*old_state)
{
struct drm_device *ddev = old_state->dev;
struct tidss_device *tidss = to_tidss(ddev);
+ bool fence_cookie = dma_fence_begin_signalling();
dev_dbg(ddev->dev, "%s\n", __func__);
@@ -36,6 +39,7 @@ static void tidss_atomic_commit_tail(struct drm_atomic_state
*old_state)
drm_atomic_helper_commit_modeset_enables(ddev, old_state);
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_wait_for_flip_done(ddev, old_state);
drm_atomic_helper_cleanup_planes(ddev, old_state);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/25] drm/scheduler: use dma-fence annotations in main thread
If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.
Add dma-fence annotations so that lockdep can check this for us.
I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no expert on drm scheduler.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/scheduler/sched_main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index d6eaa23ad746..52f1ab4bc922 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -765,9 +765,12 @@ static int drm_sched_main(void *param)
struct sched_param sparam = {.sched_priority = 1};
struct drm_gpu_scheduler *sched = (struct drm_gpu_scheduler *)param;
int r;
+ bool fence_cookie;
sched_setscheduler(current, SCHED_FIFO, &sparam);
+ fence_cookie = dma_fence_begin_signalling();
+
while (!kthread_should_stop()) {
struct drm_sched_entity *entity = NULL;
struct drm_sched_fence *s_fence;
@@ -825,6 +828,9 @@ static int drm_sched_main(void *param)
wake_up(&sched->job_scheduled);
}
+
+ dma_fence_end_signalling(fence_cookie);
+
return 0;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/25] drm/atmel: Use drm_atomic_helper_commit
One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.
Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few lines deleted. But I'm not looking at that
stuff, I'm just going through all the atomic commit functions and make
sure they have properly annotated dma-fence critical sections
everywhere.
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 96 +---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 4 -
2 files changed, 1 insertion(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 871293d1aeeb..9ec156e98f06 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq,
void *data)
return IRQ_HANDLED;
}
-struct atmel_hlcdc_dc_commit {
- struct work_struct work;
- struct drm_device *dev;
- struct drm_atomic_state *state;
-};
-
-static void
-atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
-{
- struct drm_device *dev = commit->dev;
- struct atmel_hlcdc_dc *dc = dev->dev_private;
- struct drm_atomic_state *old_state = commit->state;
-
- /* Apply the atomic update. */
- drm_atomic_helper_commit_modeset_disables(dev, old_state);
- drm_atomic_helper_commit_planes(dev, old_state, 0);
- drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_wait_for_vblanks(dev, old_state);
-
- drm_atomic_helper_cleanup_planes(dev, old_state);
-
- drm_atomic_state_put(old_state);
-
- /* Complete the commit, wake up any waiter. */
- spin_lock(&dc->commit.wait.lock);
- dc->commit.pending = false;
- wake_up_all_locked(&dc->commit.wait);
- spin_unlock(&dc->commit.wait.lock);
-
- kfree(commit);
-}
-
-static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
-{
- struct atmel_hlcdc_dc_commit *commit =
- container_of(work, struct atmel_hlcdc_dc_commit, work);
-
- atmel_hlcdc_dc_atomic_complete(commit);
-}
-
-static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
-{
- struct atmel_hlcdc_dc *dc = dev->dev_private;
- struct atmel_hlcdc_dc_commit *commit;
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- /* Allocate the commit object. */
- commit = kzalloc(sizeof(*commit), GFP_KERNEL);
- if (!commit) {
- ret = -ENOMEM;
- goto error;
- }
-
- INIT_WORK(&commit->work, atmel_hlcdc_dc_atomic_work);
- commit->dev = dev;
- commit->state = state;
-
- spin_lock(&dc->commit.wait.lock);
- ret = wait_event_interruptible_locked(dc->commit.wait,
- !dc->commit.pending);
- if (ret == 0)
- dc->commit.pending = true;
- spin_unlock(&dc->commit.wait.lock);
-
- if (ret)
- goto err_free;
-
- /* We have our own synchronization through the commit lock. */
- BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
- /* Swap state succeeded, this is the point of no return. */
- drm_atomic_state_get(state);
- if (async)
- queue_work(dc->wq, &commit->work);
- else
- atmel_hlcdc_dc_atomic_complete(commit);
-
- return 0;
-
-err_free:
- kfree(commit);
-error:
- drm_atomic_helper_cleanup_planes(dev, state);
- return ret;
-}
-
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
- .atomic_commit = atmel_hlcdc_dc_atomic_commit,
+ .atomic_commit = drm_atomic_helper_commit,
};
static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
@@ -716,7 +623,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
if (!dc->wq)
return -ENOMEM;
- init_waitqueue_head(&dc->commit.wait);
dc->desc = match->data;
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 469d4507e576..9367a3747a3a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -346,10 +346,6 @@ struct atmel_hlcdc_d
[Intel-gfx] [PATCH 08/25] drm/malidp: Annotate dma-fence critical section in commit path
Again needs to be put right after the call to drm_atomic_helper_commit_hw_done(), since that's the last thing which can hold up a subsequent atomic commit. No surprises here. Signed-off-by: Daniel Vetter Cc: "James (Qian) Wang" Cc: Liviu Dudau Cc: Mihail Atanassov --- drivers/gpu/drm/arm/malidp_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index 69fee05c256c..26e60401a8e1 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -234,6 +234,7 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state *state) struct drm_crtc *crtc; struct drm_crtc_state *old_crtc_state; int i; + bool fence_cookie = dma_fence_begin_signalling(); pm_runtime_get_sync(drm->dev); @@ -260,6 +261,8 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state *state) malidp_atomic_commit_hw_done(state); + dma_fence_end_signalling(fence_cookie); + pm_runtime_put(drm->dev); drm_atomic_helper_cleanup_planes(drm, state); -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/25] drm/amdgpu: add dma-fence annotations to atomic commit path
I need a canary in a ttm-based atomic driver to make sure the dma_fence_begin/end_signalling annotations actually work. Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 5b0f708dd8c5..6afcc33ff846 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -57,6 +57,7 @@ #include "ivsrcid/ivsrcid_vislands30.h" +#include #include #include #include @@ -7359,6 +7360,9 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state) struct drm_connector_state *old_con_state, *new_con_state; struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; int crtc_disable_count = 0; + bool fence_cookie; + + fence_cookie = dma_fence_begin_signalling(); drm_atomic_helper_update_legacy_modeset_state(dev, state); @@ -7639,6 +7643,8 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state) /* Signal HW programming completion */ drm_atomic_helper_commit_hw_done(state); + dma_fence_end_signalling(fence_cookie); + if (wait_for_vblank) drm_atomic_helper_wait_for_flip_done(dev, state); -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/25] drm/omapdrm: Annotate dma-fence critical section in commit path
Nothing special, just put the end right after hw_done(). Note that in
one path there's a wait for the flip/update to complete. But as far as
I understand from comments and code that's only relevant for modesets,
and skipped if there wasn't a modeset done on a given crtc.
For a bit more clarity pull the hw_done() call out of the if/else,
that way it's a bit clearer flow. But happy to shuffle this around as
is seen fit.
Signed-off-by: Daniel Vetter
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 4526967978b7..aa3a8034d0ea 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -68,6 +68,7 @@ static void omap_atomic_commit_tail(struct drm_atomic_state
*old_state)
{
struct drm_device *dev = old_state->dev;
struct omap_drm_private *priv = dev->dev_private;
+ bool fence_cookie = dma_fence_begin_signalling();
priv->dispc_ops->runtime_get(priv->dispc);
@@ -90,8 +91,6 @@ static void omap_atomic_commit_tail(struct drm_atomic_state
*old_state)
omap_atomic_wait_for_completion(dev, old_state);
drm_atomic_helper_commit_planes(dev, old_state, 0);
-
- drm_atomic_helper_commit_hw_done(old_state);
} else {
/*
* OMAP3 DSS seems to have issues with the work-around above,
@@ -101,10 +100,12 @@ static void omap_atomic_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_planes(dev, old_state, 0);
drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_commit_hw_done(old_state);
}
+ drm_atomic_helper_commit_hw_done(old_state);
+
+ dma_fence_end_signalling(fence_cookie);
+
/*
* Wait for completion of the page flips to ensure that old buffers
* can't be touched by the hardware anymore before cleaning up planes.
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/25] drm/komdea: Annotate dma-fence critical section in commit path
Like the helpers, nothing special. Well except not, because we the
critical section extends until after hw_done(), since that's the last
thing which could hold up a subsequent atomic commit. That means the
wait_for_flip_done is included, but that's not a problem, we're
allowed to call dma_fence_wait() from signalling critical sections.
Even on our own fence (which this does), it's just a bit confusing.
But in a way those last 2 function calls are already part of the fence
signalling critical section for the next atomic commit.
Reading this I'm wondering why komeda waits for flip_done() before
calling hw_done(), which is a bit backwards (but hey hw can be
special). Might be good to throw a comment in there that explains why,
because the original commit that added this just doesn't.
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 1f6682032ca4..cc5b5915bc5e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -73,6 +73,7 @@ static struct drm_driver komeda_kms_driver = {
static void komeda_kms_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -85,6 +86,8 @@ static void komeda_kms_commit_tail(struct drm_atomic_state
*old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_cleanup_planes(dev, old_state);
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/25] drm/atomic-helper: Add dma-fence annotations
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
implementations of this hook right now), so bad flag day. And also a
bit leaky abstraction.
Hence just do it function-by-function.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c6bf9722b51b..f67ee513a7cc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1550,6 +1550,7 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -1561,6 +1562,8 @@ void drm_atomic_helper_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1580,6 +1583,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -1592,6 +1596,8 @@ void drm_atomic_helper_commit_tail_rpm(struct
drm_atomic_state *old_state)
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
+
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
@@ -1607,6 +1613,9 @@ static void commit_tail(struct drm_atomic_state
*old_state)
ktime_t start;
s64 commit_time_ms;
unsigned int i, new_self_refresh_mask = 0;
+ bool fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
funcs = dev->mode_config.helper_private;
@@ -1635,6 +1644,8 @@ static void commit_tail(struct drm_atomic_state
*old_state)
if (new_crtc_state->self_refresh_active)
new_self_refresh_mask |= BIT(i);
+ dma_fence_end_signalling(fence_cookie);
+
if (funcs && funcs->atomic_commit_tail)
funcs->atomic_commit_tail(old_state);
else
@@ -1790,6 +1801,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
bool nonblock)
{
int ret;
+ bool fence_cookie;
if (state->async_update) {
ret = drm_atomic_helper_prepare_planes(dev, state);
@@ -1812,6 +1824,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
if (ret)
return ret;
+ fence_cookie = dma_fence_begin_signalling();
+
if (!nonblock) {
ret = drm_atomic_helper_wait_for_fences(dev, state, true);
if (ret)
@@ -1849,6 +1863,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
*/
drm_atomic_state_get(state);
+ dma_fence_end_signalling(fence_cookie);
if (nonblock)
queue_work(system_unbound_wq, &state->commit_work);
else
@@ -1857,6 +1872,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
return 0;
err:
+ dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/25] drm/amdgpu: DC also loves to allocate stuff where it shouldn't
Not going to bother with a complete&pretty commit message, just
offending backtrace:
kvmalloc_node+0x47/0x80
dc_create_state+0x1f/0x60 [amdgpu]
dc_commit_state+0xcb/0x9b0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
commit_tail+0xa4/0x140 [drm_kms_helper]
drm_atomic_helper_commit+0x152/0x180 [drm_kms_helper]
drm_client_modeset_commit_atomic+0x1ea/0x250 [drm]
drm_client_modeset_commit_locked+0x55/0x190 [drm]
drm_client_modeset_commit+0x24/0x40 [drm]
v2: Found more in DC code, I'm just going to pile them all up.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/atom.c | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 4cfc786699c7..1b0c674fab25 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -1226,7 +1226,7 @@ static int amdgpu_atom_execute_table_locked(struct
atom_context *ctx, int index,
ectx.abort = false;
ectx.last_jump = 0;
if (ws)
- ectx.ws = kcalloc(4, ws, GFP_KERNEL);
+ ectx.ws = kcalloc(4, ws, GFP_ATOMIC);
else
ectx.ws = NULL;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6afcc33ff846..3d41eddc7908 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6872,7 +6872,7 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
struct dc_stream_update stream_update;
} *bundle;
- bundle = kzalloc(sizeof(*bundle), GFP_KERNEL);
+ bundle = kzalloc(sizeof(*bundle), GFP_ATOMIC);
if (!bundle) {
dm_error("Failed to allocate update bundle\n");
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 942ceb0f6383..f9a58509efb2 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1475,8 +1475,10 @@ bool dc_post_update_surfaces_to_stream(struct dc *dc)
struct dc_state *dc_create_state(struct dc *dc)
{
+ /* No you really cant allocate random crap here this late in
+* atomic_commit_tail. */
struct dc_state *context = kvzalloc(sizeof(struct dc_state),
- GFP_KERNEL);
+ GFP_ATOMIC);
if (!context)
return NULL;
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/25] drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to bother, READ_ONCE is
equivalent. And avoids the locking issue.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3d41eddc7908..d6bb876a74e5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6949,7 +6949,11 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* explicitly on fences instead
* and in general should be called for
* blocking commit to as per framework helpers
+*
+* Yes, this deadlocks, since you're calling dma_resv_lock in a
+* path that leads to a dma_fence_signal(). Don't do that.
*/
+#if 0
r = amdgpu_bo_reserve(abo, true);
if (unlikely(r != 0))
DRM_ERROR("failed to reserve buffer before flip\n");
@@ -6959,6 +6963,12 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
tmz_surface = amdgpu_bo_encrypted(abo);
amdgpu_bo_unreserve(abo);
+#endif
+ /*
+* this races anyway, so READ_ONCE isn't any better or worse
+* than the stuff above. Except the stuff above can deadlock.
+*/
+ tiling_flags = READ_ONCE(abo->tiling_flags);
fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/25] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code
My dma-fence lockdep annotations caught an inversion because we allocate memory where we really shouldn't: kmem_cache_alloc+0x2b/0x6d0 amdgpu_fence_emit+0x30/0x330 [amdgpu] amdgpu_ib_schedule+0x306/0x550 [amdgpu] amdgpu_job_run+0x10f/0x260 [amdgpu] drm_sched_main+0x1b9/0x490 [gpu_sched] kthread+0x12e/0x150 Trouble right now is that lockdep only validates against GFP_FS, which would be good enough for shrinkers. But for mmu_notifiers we actually need !GFP_ATOMIC, since they can be called from any page laundering, even if GFP_NOFS or GFP_NOIO are set. I guess we should improve the lockdep annotations for fs_reclaim_acquire/release. Ofc real fix is to properly preallocate this fence and stuff it into the amdgpu job structure. But GFP_ATOMIC gets the lockdep splat out of the way. v2: Two more allocations in scheduler paths. Frist one: __kmalloc+0x58/0x720 amdgpu_vmid_grab+0x100/0xca0 [amdgpu] amdgpu_job_dependency+0xf9/0x120 [amdgpu] drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] drm_sched_main+0xf9/0x490 [gpu_sched] Second one: kmem_cache_alloc+0x2b/0x6d0 amdgpu_sync_fence+0x7e/0x110 [amdgpu] amdgpu_vmid_grab+0x86b/0xca0 [amdgpu] amdgpu_job_dependency+0xf9/0x120 [amdgpu] drm_sched_entity_pop_job+0x3f/0x440 [gpu_sched] drm_sched_main+0xf9/0x490 [gpu_sched] Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c index 8d84975885cd..a089a827fdfe 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c @@ -143,7 +143,7 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **f, uint32_t seq; int r; - fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_KERNEL); + fence = kmem_cache_alloc(amdgpu_fence_slab, GFP_ATOMIC); if (fence == NULL) return -ENOMEM; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c index 267fa45ddb66..a333ca2d4ddd 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c @@ -208,7 +208,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm, if (ring->vmid_wait && !dma_fence_is_signaled(ring->vmid_wait)) return amdgpu_sync_fence(sync, ring->vmid_wait); - fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_KERNEL); + fences = kmalloc_array(sizeof(void *), id_mgr->num_ids, GFP_ATOMIC); if (!fences) return -ENOMEM; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c index 8ea6c49529e7..af22b526cec9 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c @@ -160,7 +160,7 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct dma_fence *f) if (amdgpu_sync_add_later(sync, f)) return 0; - e = kmem_cache_alloc(amdgpu_sync_slab, GFP_KERNEL); + e = kmem_cache_alloc(amdgpu_sync_slab, GFP_ATOMIC); if (!e) return -ENOMEM; -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/25] drm/tegra: Annotate dma-fence critical section in commit path
Again ends just after drm_atomic_helper_commit_hw_done(), but with the
twist that we need to make sure we're only annotate the custom
version. And not the other clause which just calls
drm_atomic_helper_commit_tail_rpm(), which is already annotated.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/drm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index ba9d1c3e7cac..9aea8fe48db3 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -65,11 +65,14 @@ static void tegra_atomic_commit_tail(struct
drm_atomic_state *old_state)
struct tegra_drm *tegra = drm->dev_private;
if (tegra->hub) {
+ bool fence_cookie = dma_fence_begin_signalling();
+
drm_atomic_helper_commit_modeset_disables(drm, old_state);
tegra_display_hub_atomic_commit(drm, old_state);
drm_atomic_helper_commit_planes(drm, old_state, 0);
drm_atomic_helper_commit_modeset_enables(drm, old_state);
drm_atomic_helper_commit_hw_done(old_state);
+ dma_fence_end_signalling(fence_cookie);
drm_atomic_helper_wait_for_vblanks(drm, old_state);
drm_atomic_helper_cleanup_planes(drm, old_state);
} else {
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/25] drm/tilcdc: Use standard drm_atomic_helper_commit
Gives us proper nonblocking support for free, and a pile of other
things. The tilcdc code is simply old enough that it was never
converted over, but was stuck forever with the copypasta from when it
was initially merged.
The riskiest thing with this conversion is maybe that there's an issue
with the vblank handling or vblank event handling, which will upset
the modern commit support in atomic helpers. But from a cursory review
drm_crtc_vblank_on/off is called in the right places, and the event
handling also seems to exist (albeit with much hand-rolling and
probably some races, could perhaps be converted over to
drm_crtc_arm_vblank_event without any real loss).
Motivated by me not having to hand-roll the dma-fence annotations for
this.
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 47 +
1 file changed, 1 insertion(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 0d74a6443263..4f5fc3e87383 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -87,55 +87,10 @@ static int tilcdc_atomic_check(struct drm_device *dev,
return ret;
}
-static int tilcdc_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
-{
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_helper_swap_state(state, true);
- if (ret) {
- drm_atomic_helper_cleanup_planes(dev, state);
- return ret;
- }
-
- /*
-* Everything below can be run asynchronously without the need to grab
-* any modeset locks at all under one condition: It must be guaranteed
-* that the asynchronous work has either been cancelled (if the driver
-* supports it, which at least requires that the framebuffers get
-* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
-* before the new state gets committed on the software side with
-* drm_atomic_helper_swap_state().
-*
-* This scheme allows new atomic state updates to be prepared and
-* checked in parallel to the asynchronous completion of the previous
-* update. Which is important since compositors need to figure out the
-* composition of the next frame right after having submitted the
-* current layout.
-*/
-
- drm_atomic_helper_commit_modeset_disables(dev, state);
-
- drm_atomic_helper_commit_planes(dev, state, 0);
-
- drm_atomic_helper_commit_modeset_enables(dev, state);
-
- drm_atomic_helper_wait_for_vblanks(dev, state);
-
- drm_atomic_helper_cleanup_planes(dev, state);
-
- return 0;
-}
-
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = tilcdc_atomic_check,
- .atomic_commit = tilcdc_commit,
+ .atomic_commit = drm_atomic_helper_commit,
};
static void modeset_init(struct drm_device *dev)
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 22/25] drm/scheduler: use dma-fence annotations in tdr work
In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.
Originally this was part of the overall scheduler annotation patch.
But amdgpu has some glorious inversions here:
- grabs console_lock
- does a full modeset, which grabs all kinds of locks
(drm_modeset_lock, dma_resv_lock) which can deadlock with
dma_fence_wait held inside them.
- almost minor at that point, but the modeset code also allocates
memory
These all look like they'll be very hard to fix properly, the hardware
seems to require a full display reset with any gpu recovery.
Hence split out as a seperate patch.
Since amdgpu isn't the only hardware driver that needs to reset the
display (at least gen2/3 on intel have the same problem) we need a
generic solution for this. There's two tricks we could still from
drm/i915 and lift to dma-fence:
- The big whack, aka force-complete all fences. i915 does this for all
pending jobs if the reset is somehow stuck. Trouble is we'd need to
do this for all fences in the entire system, and just the
book-keeping for that will be fun. Plus lots of drivers use fences
for all kinds of internal stuff like memory management, so
unconditionally resetting all of them doesn't work.
I'm also hoping that with these fence annotations we could enlist
lockdep in finding the last offenders causing deadlocks, and we
could remove this get-out-of-jail trick.
- The more feasible approach (across drivers at least as part of the
dma_fence contract) is what drm/i915 does for gen2/3: When we need
to reset the display we wake up all dma_fence_wait_interruptible
calls, or well at least the equivalent of those in i915 internally.
Relying on ioctl restart we force all other threads to release their
locks, which means the tdr thread is guaranteed to be able to get
them. I think we could implement this at the dma_fence level,
including proper lockdep annotations.
dma_fence_begin_tdr():
- must be nested within a dma_fence_begin/end_signalling section
- will wake up all interruptible (but not the non-interruptible)
dma_fence_wait() calls and force them to complete with a
-ERESTARTSYS errno code. All new interrupitble calls to
dma_fence_wait() will immeidately fail with the same error code.
dma_fence_end_trdr():
- this will convert dma_fence_wait() calls back to normal.
Of course interrupting dma_fence_wait is only ok if the caller
specified that, which means we need to split the annotations into
interruptible and non-interruptible version. If we then make sure
that we only use interruptible dma_fence_wait() calls while holding
drm_modeset_lock we can grab them in tdr code, and allow display
resets. Doing the same for dma_resv_lock might be a lot harder, so
buffer updates must be avoided.
What's worse, we're not going to be able to make the dma_fence_wait
calls in mmu-notifiers interruptible, that doesn't work. So
allocating memory still wont' be allowed, even in tdr sections. Plus
obviously we can use this trick only in tdr, it is rather intrusive.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/scheduler/sched_main.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 52f1ab4bc922..a1c091e11ffd 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -281,9 +281,12 @@ static void drm_sched_job_timedout(struct work_struct
*work)
{
struct drm_gpu_scheduler *sched;
struct drm_sched_job *job;
+ bool fence_cookie;
sched = container_of(work, struct drm_gpu_scheduler, work_tdr.work);
+ fence_cookie = dma_fence_begin_signalling();
+
/* Protects against concurrent deletion in drm_sched_get_cleanup_job */
spin_lock(&sched->job_list_lock);
job = list_first_entry_or_null(&sched->ring_mirror_list,
@@ -315,6 +318,8 @@ static void drm_sched_job_timedout(struct work_struct *work)
spin_lock(&sched->job_list_lock);
drm_sched_start_timeout(sched);
spin_unlock(&sched->job_list_lock);
+
+ dma_fence_end_signalling(fence_cookie);
}
/**
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/25] drm/amdgpu: use dma-fence annotations in cs_submit()
This is a bit tricky, since ->notifier_lock is held while calling dma_fence_wait we must ensure that also the read side (i.e. dma_fence_begin_signalling) is on the same side. If we mix this up lockdep complaints, and that's again why we want to have these annotations. A nice side effect of this is that because of the fs_reclaim priming for dma_fence_enable lockdep now automatically checks for us that nothing in here allocates memory, without even running any userptr workloads. Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index a512ccbc4dea..858528a06fe7 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1212,6 +1212,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, struct amdgpu_job *job; uint64_t seq; int r; + bool fence_cookie; job = p->job; p->job = NULL; @@ -1226,6 +1227,8 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, */ mutex_lock(&p->adev->notifier_lock); + fence_cookie = dma_fence_begin_signalling(); + /* If userptr are invalidated after amdgpu_cs_parser_bos(), return * -EAGAIN, drmIoctl in libdrm will restart the amdgpu_cs_ioctl. */ @@ -1262,12 +1265,14 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, amdgpu_vm_move_to_lru_tail(p->adev, &fpriv->vm); ttm_eu_fence_buffer_objects(&p->ticket, &p->validated, p->fence); + dma_fence_end_signalling(fence_cookie); mutex_unlock(&p->adev->notifier_lock); return 0; error_abort: drm_sched_job_cleanup(&job->base); + dma_fence_end_signalling(fence_cookie); mutex_unlock(&p->adev->notifier_lock); error_unlock: -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 25/25] drm/amdgpu: gpu recovery does full modesets
...
I think it's time to stop this little exercise.
The lockdep splat, for the record:
[ 132.583381] ==
[ 132.584091] WARNING: possible circular locking dependency detected
[ 132.584775] 5.7.0-rc3+ #346 Tainted: GW
[ 132.585461] --
[ 132.586184] kworker/2:3/865 is trying to acquire lock:
[ 132.586857] c9677c70 (crtc_ww_class_acquire){+.+.}-{0:0}, at:
drm_atomic_helper_suspend+0x38/0x120 [drm_kms_helper]
[ 132.587569]
but task is already holding lock:
[ 132.589044] 82318c80 (dma_fence_map){}-{0:0}, at:
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[ 132.589803]
which lock already depends on the new lock.
[ 132.592009]
the existing dependency chain (in reverse order) is:
[ 132.593507]
-> #2 (dma_fence_map){}-{0:0}:
[ 132.595019]dma_fence_begin_signalling+0x50/0x60
[ 132.595767]drm_atomic_helper_commit+0xa1/0x180 [drm_kms_helper]
[ 132.596567]drm_client_modeset_commit_atomic+0x1ea/0x250 [drm]
[ 132.597420]drm_client_modeset_commit_locked+0x55/0x190 [drm]
[ 132.598178]drm_client_modeset_commit+0x24/0x40 [drm]
[ 132.598948]drm_fb_helper_restore_fbdev_mode_unlocked+0x4b/0xa0
[drm_kms_helper]
[ 132.599738]drm_fb_helper_set_par+0x30/0x40 [drm_kms_helper]
[ 132.600539]fbcon_init+0x2e8/0x660
[ 132.601344]visual_init+0xce/0x130
[ 132.602156]do_bind_con_driver+0x1bc/0x2b0
[ 132.602970]do_take_over_console+0x115/0x180
[ 132.603763]do_fbcon_takeover+0x58/0xb0
[ 132.604564]register_framebuffer+0x1ee/0x300
[ 132.605369]__drm_fb_helper_initial_config_and_unlock+0x36e/0x520
[drm_kms_helper]
[ 132.606187]amdgpu_fbdev_init+0xb3/0xf0 [amdgpu]
[ 132.607032]amdgpu_device_init.cold+0xe90/0x1677 [amdgpu]
[ 132.607862]amdgpu_driver_load_kms+0x5a/0x200 [amdgpu]
[ 132.608697]amdgpu_pci_probe+0xf7/0x180 [amdgpu]
[ 132.609511]local_pci_probe+0x42/0x80
[ 132.610324]pci_device_probe+0x104/0x1a0
[ 132.611130]really_probe+0x147/0x3c0
[ 132.611939]driver_probe_device+0xb6/0x100
[ 132.612766]device_driver_attach+0x53/0x60
[ 132.613593]__driver_attach+0x8c/0x150
[ 132.614419]bus_for_each_dev+0x7b/0xc0
[ 132.615249]bus_add_driver+0x14c/0x1f0
[ 132.616071]driver_register+0x6c/0xc0
[ 132.616902]do_one_initcall+0x5d/0x2f0
[ 132.617731]do_init_module+0x5c/0x230
[ 132.618560]load_module+0x2981/0x2bc0
[ 132.619391]__do_sys_finit_module+0xaa/0x110
[ 132.620228]do_syscall_64+0x5a/0x250
[ 132.621064]entry_SYSCALL_64_after_hwframe+0x49/0xb3
[ 132.621903]
-> #1 (crtc_ww_class_mutex){+.+.}-{3:3}:
[ 132.623587]__ww_mutex_lock.constprop.0+0xcc/0x10c0
[ 132.624448]ww_mutex_lock+0x43/0xb0
[ 132.625315]drm_modeset_lock+0x44/0x120 [drm]
[ 132.626184]drmm_mode_config_init+0x2db/0x8b0 [drm]
[ 132.627098]amdgpu_device_init.cold+0xbd1/0x1677 [amdgpu]
[ 132.628007]amdgpu_driver_load_kms+0x5a/0x200 [amdgpu]
[ 132.628920]amdgpu_pci_probe+0xf7/0x180 [amdgpu]
[ 132.629804]local_pci_probe+0x42/0x80
[ 132.630690]pci_device_probe+0x104/0x1a0
[ 132.631583]really_probe+0x147/0x3c0
[ 132.632479]driver_probe_device+0xb6/0x100
[ 132.633379]device_driver_attach+0x53/0x60
[ 132.634275]__driver_attach+0x8c/0x150
[ 132.635170]bus_for_each_dev+0x7b/0xc0
[ 132.636069]bus_add_driver+0x14c/0x1f0
[ 132.636974]driver_register+0x6c/0xc0
[ 132.637870]do_one_initcall+0x5d/0x2f0
[ 132.638765]do_init_module+0x5c/0x230
[ 132.639654]load_module+0x2981/0x2bc0
[ 132.640522]__do_sys_finit_module+0xaa/0x110
[ 132.641372]do_syscall_64+0x5a/0x250
[ 132.642203]entry_SYSCALL_64_after_hwframe+0x49/0xb3
[ 132.643022]
-> #0 (crtc_ww_class_acquire){+.+.}-{0:0}:
[ 132.644643]__lock_acquire+0x1241/0x23f0
[ 132.645469]lock_acquire+0xad/0x370
[ 132.646274]drm_modeset_acquire_init+0xd2/0x100 [drm]
[ 132.647071]drm_atomic_helper_suspend+0x38/0x120 [drm_kms_helper]
[ 132.647902]dm_suspend+0x1c/0x60 [amdgpu]
[ 132.648698]amdgpu_device_ip_suspend_phase1+0x83/0xe0 [amdgpu]
[ 132.649498]amdgpu_device_ip_suspend+0x1c/0x60 [amdgpu]
[ 132.650300]amdgpu_device_gpu_recover.cold+0x4e6/0xe64 [amdgpu]
[ 132.651084]amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[ 132.651825]drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[ 132.652594]process_one_work+0x23c/0x580
[ 132.653402]worker_thread+0x50/0x3b0
[ 132.654139]kthread+0x12e/0x150
[ 132.654868]ret_from_fork+0x27/0x50
[ 132.655598]
[Intel-gfx] [PATCH 10/25] drm/imx: Annotate dma-fence critical section in commit path
drm_atomic_helper_commit_hw_done() is the last thing (no plane cleanup
apparrently), so it's the entire function. And a nice comment
explaining why thw wait_for_flip_done is ahead, unlike the usual
sequence.
Aside, I think since the atomic helpers do track plane disabling now
separately this might no longer be a real problem since:
commit 21a01abbe32a3cbeb903378a24e504bfd9fe0648
Author: Maarten Lankhorst
Date: Mon Sep 4 12:48:37 2017 +0200
drm/atomic: Fix freeing connector/plane state too early by tracking
commits, v3.
Plus the subsequent bugfixes of course, this was tricky to get right.
Signed-off-by: Daniel Vetter
Cc: Philipp Zabel
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 36037b2e6564..8c209bd36780 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -80,6 +80,7 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
struct drm_plane_state *old_plane_state, *new_plane_state;
bool plane_disabling = false;
int i;
+ bool fence_cookie = dma_fence_begin_signalling();
drm_atomic_helper_commit_modeset_disables(dev, state);
@@ -110,6 +111,7 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
}
drm_atomic_helper_commit_hw_done(state);
+ dma_fence_end_signalling(fence_cookie);
}
static const struct drm_mode_config_helper_funcs imx_drm_mode_config_helpers =
{
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/25] drm/amdgpu: use dma-fence annotations for gpu reset code
To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a649e40fd96f..3a3bccd7f1c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4261,6 +4261,9 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
(amdgpu_asic_reset_method(adev) == AMD_RESET_METHOD_BACO) ?
true : false;
bool audio_suspended = false;
+ bool fence_cookie;
+
+ fence_cookie = dma_fence_begin_signalling();
/*
* Flush RAM to disk so that after reboot
@@ -4289,6 +4292,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as another
already in progress",
job ? job->base.id : -1, hive->hive_id);
mutex_unlock(&hive->hive_lock);
+ dma_fence_end_signalling(fence_cookie);
return 0;
}
@@ -4299,8 +4303,10 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
*/
INIT_LIST_HEAD(&device_list);
if (adev->gmc.xgmi.num_physical_nodes > 1) {
- if (!hive)
+ if (!hive) {
+ dma_fence_end_signalling(fence_cookie);
return -ENODEV;
+ }
if (!list_is_first(&adev->gmc.xgmi.head, &hive->device_list))
list_rotate_to_front(&adev->gmc.xgmi.head,
&hive->device_list);
device_list_handle = &hive->device_list;
@@ -4315,6 +4321,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
DRM_INFO("Bailing on TDR for s_job:%llx, as another
already in progress",
job ? job->base.id : -1);
mutex_unlock(&hive->hive_lock);
+ dma_fence_end_signalling(fence_cookie);
return 0;
}
@@ -4455,6 +4462,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
if (r)
dev_info(adev->dev, "GPU reset end with ret = %d\n", r);
+ dma_fence_end_signalling(fence_cookie);
return r;
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/25] drm/rcar-du: Annotate dma-fence critical section in commit path
Ends right after drm_atomic_helper_commit_hw_done(), absolutely nothing fancy going on here. Signed-off-by: Daniel Vetter Cc: Laurent Pinchart Cc: Kieran Bingham Cc: linux-renesas-...@vger.kernel.org --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 482329102f19..42c5dc588435 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -391,6 +391,7 @@ static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state) struct drm_crtc_state *crtc_state; struct drm_crtc *crtc; unsigned int i; + bool fence_cookie = dma_fence_begin_signalling(); /* * Store RGB routing to DPAD0 and DPAD1, the hardware will be configured @@ -417,6 +418,7 @@ static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state) drm_atomic_helper_commit_modeset_enables(dev, old_state); drm_atomic_helper_commit_hw_done(old_state); + dma_fence_end_signalling(fence_cookie); drm_atomic_helper_wait_for_flip_done(dev, old_state); drm_atomic_helper_cleanup_planes(dev, old_state); -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 24/25] Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset"
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be held when we allocate memory, which
might never happen because the dma_fence_wait() is stuck waiting on
our gpu reset:
[ 136.763714] ==
[ 136.763714] WARNING: possible circular locking dependency detected
[ 136.763715] 5.7.0-rc3+ #346 Tainted: GW
[ 136.763716] --
[ 136.763716] kworker/2:3/682 is trying to acquire lock:
[ 136.763716] 8226f140 (console_lock){+.+.}-{0:0}, at:
drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763723]
but task is already holding lock:
[ 136.763724] 82318c80 (dma_fence_map){}-{0:0}, at:
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[ 136.763726]
which lock already depends on the new lock.
[ 136.763726]
the existing dependency chain (in reverse order) is:
[ 136.763727]
-> #2 (dma_fence_map){}-{0:0}:
[ 136.763730]__dma_fence_might_wait+0x41/0xb0
[ 136.763732]dma_resv_lockdep+0x171/0x202
[ 136.763734]do_one_initcall+0x5d/0x2f0
[ 136.763736]kernel_init_freeable+0x20d/0x26d
[ 136.763738]kernel_init+0xa/0xfb
[ 136.763740]ret_from_fork+0x27/0x50
[ 136.763740]
-> #1 (fs_reclaim){+.+.}-{0:0}:
[ 136.763743]fs_reclaim_acquire.part.0+0x25/0x30
[ 136.763745]kmem_cache_alloc_trace+0x2e/0x6e0
[ 136.763747]device_create_groups_vargs+0x52/0xf0
[ 136.763747]device_create+0x49/0x60
[ 136.763749]fb_console_init+0x25/0x145
[ 136.763750]fbmem_init+0xcc/0xe2
[ 136.763750]do_one_initcall+0x5d/0x2f0
[ 136.763751]kernel_init_freeable+0x20d/0x26d
[ 136.763752]kernel_init+0xa/0xfb
[ 136.763753]ret_from_fork+0x27/0x50
[ 136.763753]
-> #0 (console_lock){+.+.}-{0:0}:
[ 136.763755]__lock_acquire+0x1241/0x23f0
[ 136.763756]lock_acquire+0xad/0x370
[ 136.763757]console_lock+0x47/0x70
[ 136.763761]drm_fb_helper_set_suspend_unlocked+0x7b/0xa0
[drm_kms_helper]
[ 136.763809]amdgpu_device_gpu_recover.cold+0x21e/0xe7b [amdgpu]
[ 136.763850]amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[ 136.763851]drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[ 136.763852]process_one_work+0x23c/0x580
[ 136.763853]worker_thread+0x50/0x3b0
[ 136.763854]kthread+0x12e/0x150
[ 136.763855]ret_from_fork+0x27/0x50
[ 136.763855]
other info that might help us debug this:
[ 136.763856] Chain exists of:
console_lock --> fs_reclaim --> dma_fence_map
[ 136.763857] Possible unsafe locking scenario:
[ 136.763857]CPU0CPU1
[ 136.763857]
[ 136.763857] lock(dma_fence_map);
[ 136.763858]lock(fs_reclaim);
[ 136.763858]lock(dma_fence_map);
[ 136.763858] lock(console_lock);
[ 136.763859]
*** DEADLOCK ***
[ 136.763860] 4 locks held by kworker/2:3/682:
[ 136.763860] #0: 8887fb81c938 ((wq_completion)events){+.+.}-{0:0}, at:
process_one_work+0x1bc/0x580
[ 136.763862] #1: c9cafe58
((work_completion)(&(&sched->work_tdr)->work)){+.+.}-{0:0}, at:
process_one_work+0x1bc/0x580
[ 136.763863] #2: 82318c80 (dma_fence_map){}-{0:0}, at:
drm_sched_job_timedout+0x25/0xf0 [gpu_sched]
[ 136.763865] #3: 8887ab621748 (&adev->lock_reset){+.+.}-{3:3}, at:
amdgpu_device_gpu_recover.cold+0x5ab/0xe7b [amdgpu]
[ 136.763914]
stack backtrace:
[ 136.763915] CPU: 2 PID: 682 Comm: kworker/2:3 Tainted: GW
5.7.0-rc3+ #346
[ 136.763916] Hardware name: System manufacturer System Product Name/PRIME
X370-PRO, BIOS 4011 04/19/2018
[ 136.763918] Workqueue: events drm_sched_job_timedout [gpu_sched]
[ 136.763919] Call Trace:
[ 136.763922] dump_stack+0x8f/0xd0
[ 136.763924] check_noncircular+0x162/0x180
[ 136.763926] __lock_acquire+0x1241/0x23f0
[ 136.763927] lock_acquire+0xad/0x370
[ 136.763932] ? drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763933] ? mark_held_locks+0x2d/0x80
[ 136.763934] ? _raw_spin_unlock_irqrestore+0x46/0x60
[ 136.763936] console_lock+0x47/0x70
[ 136.763940] ? drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763944] drm_fb_helper_set_suspend_unlocked+0x7b/0xa0 [drm_kms_helper]
[ 136.763993] amdgpu_device_gpu_recover.cold+0x21e/0xe7b [amdgpu]
[ 136.764036] amdgpu_job_timedout+0xfb/0x150 [amdgpu]
[ 136.764038] drm_sched_job_timedout+0x8a/0xf0 [gpu_sched]
[ 136.764
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Implement new combo phy initialization step (rev3)
On Tue, 2020-06-30 at 15:19 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/display: Implement new combo phy initialization step (rev3) > URL : https://patchwork.freedesktop.org/series/78796/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_8677_full -> Patchwork_18039_full > > > Summary > --- > > **SUCCESS** > > No regressions found. Pushed, Matt Roper gave review in v2 version but he reviewed v3 too. > > > > Known issues > > > Here are the changes found in Patchwork_18039_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox: > - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#1528]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-kbl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-kbl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html > > * igt@i915_module_load@reload: > - shard-tglb: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 > similar issue >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-tglb3/igt@i915_module_l...@reload.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-tglb6/igt@i915_module_l...@reload.html > > * igt@kms_cursor_crc@pipe-b-cursor-64x64-random: > - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] / > [i915#95]) +2 similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-kbl7/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html > > * igt@kms_cursor_legacy@pipe-b-torture-move: > - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#128]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-tglb5/igt@kms_cursor_leg...@pipe-b-torture-move.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-tglb1/igt@kms_cursor_leg...@pipe-b-torture-move.html > > * igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-modeset@ab-vga1-hdmi-a1: > - shard-hsw: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-hsw8/igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-mode...@ab-vga1-hdmi-a1.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-hsw6/igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-mode...@ab-vga1-hdmi-a1.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: > - shard-skl: [PASS][11] -> [FAIL][12] ([i915#79]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html > > * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: > - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +3 > similar issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html > > * igt@kms_flip@plain-flip-fb-recreate-interruptible@b-edp1: > - shard-skl: [PASS][15] -> [FAIL][16] ([i915#1928]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-skl10/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@b-edp1.html > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-onoff: > - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#1635] / > [i915#95]) +13 similar issues >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-apl7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-onoff.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-apl2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-onoff.html > > * igt@kms_hdr@bpc-switch-suspend: > - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) +1 similar > issue >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8677/shard-skl5/igt@kms_...@bpc-switch-suspend.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18039/shard-skl5/igt@kms_...@bpc-switch-suspend.html > > * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: > - shard-iclb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) >[21]: > https://i
Re: [Intel-gfx] [PATCH 09/25] drm/atmel: Use drm_atomic_helper_commit
Hi Daniel.
On Tue, Jul 07, 2020 at 10:12:13PM +0200, Daniel Vetter wrote:
> One of these drivers that predates the nonblocking support in helpers,
> and hand-rolled its own thing. Entirely not anything specific here, we
> can just delete it all and replace it with the helper version.
>
> Could also perhaps use the drm_mode_config_helper_suspend/resume
> stuff, for another few lines deleted. But I'm not looking at that
> stuff, I'm just going through all the atomic commit functions and make
> sure they have properly annotated dma-fence critical sections
> everywhere.
>
> Signed-off-by: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: linux-arm-ker...@lists.infradead.org
Looks good, nice to see all this code deleted!
This more or less matches what I had concluded.
But..
atmel_hlcdc_dc.wq is no longer used - so can also be deleted.
This will delete even more code - good.
I will try to test the patch in the weekend.
Will get back if I suceed doing so.
Sam
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 96 +---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 4 -
> 2 files changed, 1 insertion(+), 99 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 871293d1aeeb..9ec156e98f06 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq,
> void *data)
> return IRQ_HANDLED;
> }
>
> -struct atmel_hlcdc_dc_commit {
> - struct work_struct work;
> - struct drm_device *dev;
> - struct drm_atomic_state *state;
> -};
> -
> -static void
> -atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
> -{
> - struct drm_device *dev = commit->dev;
> - struct atmel_hlcdc_dc *dc = dev->dev_private;
> - struct drm_atomic_state *old_state = commit->state;
> -
> - /* Apply the atomic update. */
> - drm_atomic_helper_commit_modeset_disables(dev, old_state);
> - drm_atomic_helper_commit_planes(dev, old_state, 0);
> - drm_atomic_helper_commit_modeset_enables(dev, old_state);
> -
> - drm_atomic_helper_wait_for_vblanks(dev, old_state);
> -
> - drm_atomic_helper_cleanup_planes(dev, old_state);
> -
> - drm_atomic_state_put(old_state);
> -
> - /* Complete the commit, wake up any waiter. */
> - spin_lock(&dc->commit.wait.lock);
> - dc->commit.pending = false;
> - wake_up_all_locked(&dc->commit.wait);
> - spin_unlock(&dc->commit.wait.lock);
> -
> - kfree(commit);
> -}
> -
> -static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
> -{
> - struct atmel_hlcdc_dc_commit *commit =
> - container_of(work, struct atmel_hlcdc_dc_commit, work);
> -
> - atmel_hlcdc_dc_atomic_complete(commit);
> -}
> -
> -static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
> - struct drm_atomic_state *state,
> - bool async)
> -{
> - struct atmel_hlcdc_dc *dc = dev->dev_private;
> - struct atmel_hlcdc_dc_commit *commit;
> - int ret;
> -
> - ret = drm_atomic_helper_prepare_planes(dev, state);
> - if (ret)
> - return ret;
> -
> - /* Allocate the commit object. */
> - commit = kzalloc(sizeof(*commit), GFP_KERNEL);
> - if (!commit) {
> - ret = -ENOMEM;
> - goto error;
> - }
> -
> - INIT_WORK(&commit->work, atmel_hlcdc_dc_atomic_work);
> - commit->dev = dev;
> - commit->state = state;
> -
> - spin_lock(&dc->commit.wait.lock);
> - ret = wait_event_interruptible_locked(dc->commit.wait,
> - !dc->commit.pending);
> - if (ret == 0)
> - dc->commit.pending = true;
> - spin_unlock(&dc->commit.wait.lock);
> -
> - if (ret)
> - goto err_free;
> -
> - /* We have our own synchronization through the commit lock. */
> - BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
> -
> - /* Swap state succeeded, this is the point of no return. */
> - drm_atomic_state_get(state);
> - if (async)
> - queue_work(dc->wq, &commit->work);
> - else
> - atmel_hlcdc_dc_atomic_complete(commit);
> -
> - return 0;
> -
> -err_free:
> - kfree(commit);
> -error:
> - drm_atomic_helper_cleanup_planes(dev, state);
> - return ret;
> -}
> -
> static const struct drm_mode_config_funcs mode_config_funcs = {
> .fb_create = drm_gem_fb_create,
> .atomic_check = drm_atomic_helper_check,
> - .atomic_commit = atmel_hlcdc_dc_atomic_commit,
> + .atomic_commit = drm_atomic_helper_commit,
> };
>
> static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
> @@ -716,7 +623,6 @@ static int atmel_hlcdc_dc_load(struct drm_
[Intel-gfx] [PATCH v2] drm/i915/ehl: Add new PCI ids
Two new PCI ids added to ehl. v2: added two additional PCI ids BSpec: 29153 Cc: Matt Roper Cc: Anusha Srivatsa Signed-off-by: José Roberto de Souza --- include/drm/i915_pciids.h | 4 1 file changed, 4 insertions(+) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index bc989de2aac2..d6cb28992ba0 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -588,7 +588,11 @@ INTEL_VGA_DEVICE(0x4551, info), \ INTEL_VGA_DEVICE(0x4541, info), \ INTEL_VGA_DEVICE(0x4E71, info), \ + INTEL_VGA_DEVICE(0x4557, info), \ + INTEL_VGA_DEVICE(0x4555, info), \ INTEL_VGA_DEVICE(0x4E61, info), \ + INTEL_VGA_DEVICE(0x4E57, info), \ + INTEL_VGA_DEVICE(0x4E55, info), \ INTEL_VGA_DEVICE(0x4E51, info) /* TGL */ -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/gt: Replace opencoded i915_gem_object_pin_map()
== Series Details == Series: series starting with [1/3] drm/i915/gt: Replace opencoded i915_gem_object_pin_map() URL : https://patchwork.freedesktop.org/series/79211/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3286cb8bd6d2 drm/i915/gt: Replace opencoded i915_gem_object_pin_map() 9caa553dca10 drm/i915: Release shortlived maps of longlived objects -:22: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #22: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:396: } +int i915_gem_object_release_map(struct drm_i915_gem_object *obj); total: 0 errors, 0 warnings, 1 checks, 68 lines checked b500f5a58d25 drm/i915: Remove i915_gem_object_get_dirty_page() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value
Hello Hans, On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote: > On 7/7/20 9:34 AM, Uwe Kleine-König wrote: > > On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: > > > But if we do then I think closest to the truth would be: > > > > > > state->period = UINT_MAX; > > > state->duty_cycle = 0; > > > > I'd say state->period = 1 & state->duty_cycle = 0 is a better > > representation. > > But that would suggest the output is configured for an > infinitely high output frequency, but the frequency is > actually 0, the reason why get_state needs to treat a > base_unit val of 0 special at all is to avoid a division > by 0, and in math dividing by 0 gives infinite, isn't > UINT_MAX a better way to represent infinity ? Given that duty_cycle is 0, how can to tell anything about the period when only seeing the signal (= a constant low)? Given that (ideally) a period is completed when pwm_apply_state() is called, a short period is much more sensible. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/gt: Replace opencoded i915_gem_object_pin_map()
== Series Details == Series: series starting with [1/3] drm/i915/gt: Replace opencoded i915_gem_object_pin_map() URL : https://patchwork.freedesktop.org/series/79211/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18099 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18099 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18099, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18099: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-cml-s: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-cml-s/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-cml-s/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_18099 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@i915_module_load@reload: - fi-bxt-dsi: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bxt-dsi/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-bxt-dsi/igt@i915_module_l...@reload.html - fi-tgl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-whl-u: [PASS][9] -> [DMESG-WARN][10] ([i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-glk-dsi/igt@i915_pm_...@module-reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gem_contexts: - fi-tgl-u2: [PASS][13] -> [INCOMPLETE][14] ([i915#1932] / [i915#2045]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [PASS][15] -> [DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-n3050: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - fi-icl-u2: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html * igt@vgem_basic@create: - fi-tgl-y: [PASS][21] -> [DMESG-WARN][22] ([i915#402]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@vgem_ba...@create.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18099/fi-tgl-y/igt@vgem_ba...@create.html Possible fixes * igt@gem_mmap_gtt@basic: - fi-tgl-y: [DMESG-WARN][23] ([i915#402]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/
[Intel-gfx] [PATCH] drm/atmel: Use drm_atomic_helper_commit
One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.
Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few lines deleted. But I'm not looking at that
stuff, I'm just going through all the atomic commit functions and make
sure they have properly annotated dma-fence critical sections
everywhere.
v2:
- Also delete the workqueue (Sam)
- drop the @commit kerneldoc, I missed that one.
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 107 +--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 7 --
2 files changed, 2 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 871293d1aeeb..03984932d174 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -557,103 +557,10 @@ static irqreturn_t atmel_hlcdc_dc_irq_handler(int irq,
void *data)
return IRQ_HANDLED;
}
-struct atmel_hlcdc_dc_commit {
- struct work_struct work;
- struct drm_device *dev;
- struct drm_atomic_state *state;
-};
-
-static void
-atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
-{
- struct drm_device *dev = commit->dev;
- struct atmel_hlcdc_dc *dc = dev->dev_private;
- struct drm_atomic_state *old_state = commit->state;
-
- /* Apply the atomic update. */
- drm_atomic_helper_commit_modeset_disables(dev, old_state);
- drm_atomic_helper_commit_planes(dev, old_state, 0);
- drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_wait_for_vblanks(dev, old_state);
-
- drm_atomic_helper_cleanup_planes(dev, old_state);
-
- drm_atomic_state_put(old_state);
-
- /* Complete the commit, wake up any waiter. */
- spin_lock(&dc->commit.wait.lock);
- dc->commit.pending = false;
- wake_up_all_locked(&dc->commit.wait);
- spin_unlock(&dc->commit.wait.lock);
-
- kfree(commit);
-}
-
-static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
-{
- struct atmel_hlcdc_dc_commit *commit =
- container_of(work, struct atmel_hlcdc_dc_commit, work);
-
- atmel_hlcdc_dc_atomic_complete(commit);
-}
-
-static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
-{
- struct atmel_hlcdc_dc *dc = dev->dev_private;
- struct atmel_hlcdc_dc_commit *commit;
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- /* Allocate the commit object. */
- commit = kzalloc(sizeof(*commit), GFP_KERNEL);
- if (!commit) {
- ret = -ENOMEM;
- goto error;
- }
-
- INIT_WORK(&commit->work, atmel_hlcdc_dc_atomic_work);
- commit->dev = dev;
- commit->state = state;
-
- spin_lock(&dc->commit.wait.lock);
- ret = wait_event_interruptible_locked(dc->commit.wait,
- !dc->commit.pending);
- if (ret == 0)
- dc->commit.pending = true;
- spin_unlock(&dc->commit.wait.lock);
-
- if (ret)
- goto err_free;
-
- /* We have our own synchronization through the commit lock. */
- BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
-
- /* Swap state succeeded, this is the point of no return. */
- drm_atomic_state_get(state);
- if (async)
- queue_work(dc->wq, &commit->work);
- else
- atmel_hlcdc_dc_atomic_complete(commit);
-
- return 0;
-
-err_free:
- kfree(commit);
-error:
- drm_atomic_helper_cleanup_planes(dev, state);
- return ret;
-}
-
static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
- .atomic_commit = atmel_hlcdc_dc_atomic_commit,
+ .atomic_commit = drm_atomic_helper_commit,
};
static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
@@ -712,11 +619,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
if (!dc)
return -ENOMEM;
- dc->wq = alloc_ordered_workqueue("atmel-hlcdc-dc", 0);
- if (!dc->wq)
- return -ENOMEM;
-
- init_waitqueue_head(&dc->commit.wait);
dc->desc = match->data;
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
@@ -724,7 +626,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
[Intel-gfx] [PATCH 1/2] drm/i915/uc: Extract uc usage details into separate debugfs
From: Michał Winiarski
It has been pointed out that information about HuC usage doesn't belong
in guc_info debugfs. Let's move "supported/used/wanted" matrix to a
separate debugfs file, keeping guc_info strictly about GuC.
Suggested-by: Daniele Ceraolo Spurio
Signed-off-by: Michał Winiarski
Cc: Daniele Ceraolo Spurio
Cc: Lukasz Fiedorowicz
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 23 +--
drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 29 +++
2 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 446a41946f56..861657897c0f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -733,28 +733,19 @@ int intel_guc_allocate_and_map_vma(struct intel_guc *guc,
u32 size,
*/
void intel_guc_load_status(struct intel_guc *guc, struct drm_printer *p)
{
- struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
struct intel_gt *gt = guc_to_gt(guc);
struct intel_uncore *uncore = gt->uncore;
intel_wakeref_t wakeref;
- drm_printf(p, "[guc] supported:%s wanted:%s used:%s\n",
- yesno(intel_uc_supports_guc(uc)),
- yesno(intel_uc_wants_guc(uc)),
- yesno(intel_uc_uses_guc(uc)));
- drm_printf(p, "[huc] supported:%s wanted:%s used:%s\n",
- yesno(intel_uc_supports_huc(uc)),
- yesno(intel_uc_wants_huc(uc)),
- yesno(intel_uc_uses_huc(uc)));
- drm_printf(p, "[submission] supported:%s wanted:%s used:%s\n",
- yesno(intel_uc_supports_guc_submission(uc)),
- yesno(intel_uc_wants_guc_submission(uc)),
- yesno(intel_uc_uses_guc_submission(uc)));
-
- if (!intel_guc_is_supported(guc) || !intel_guc_is_wanted(guc))
+ if (!intel_guc_is_supported(guc)) {
+ drm_printf(p, "GuC not supported\n");
return;
+ }
- drm_puts(p, "\n");
+ if (!intel_guc_is_wanted(guc)) {
+ drm_printf(p, "GuC disabled\n");
+ return;
+ }
intel_uc_fw_dump(&guc->fw, p);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
index 9d16b784aa0d..089d98662f46 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
@@ -4,14 +4,41 @@
*/
#include
+#include
+#include "gt/debugfs_gt.h"
#include "intel_guc_debugfs.h"
#include "intel_huc_debugfs.h"
#include "intel_uc.h"
#include "intel_uc_debugfs.h"
+static int uc_usage_show(struct seq_file *m, void *data)
+{
+ struct intel_uc *uc = m->private;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ drm_printf(&p, "[guc] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_guc(uc)),
+ yesno(intel_uc_wants_guc(uc)),
+ yesno(intel_uc_uses_guc(uc)));
+ drm_printf(&p, "[huc] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_huc(uc)),
+ yesno(intel_uc_wants_huc(uc)),
+ yesno(intel_uc_uses_huc(uc)));
+ drm_printf(&p, "[submission] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_guc_submission(uc)),
+ yesno(intel_uc_wants_guc_submission(uc)),
+ yesno(intel_uc_uses_guc_submission(uc)));
+
+ return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(uc_usage);
+
void intel_uc_debugfs_register(struct intel_uc *uc, struct dentry *gt_root)
{
+ static const struct debugfs_gt_file files[] = {
+ { "usage", &uc_usage_fops, NULL },
+ };
struct dentry *root;
if (!gt_root)
@@ -25,6 +52,8 @@ void intel_uc_debugfs_register(struct intel_uc *uc, struct
dentry *gt_root)
if (IS_ERR(root))
return;
+ intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), uc);
+
intel_guc_debugfs_register(&uc->guc, root);
intel_huc_debugfs_register(&uc->huc, root);
}
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/huc: Adjust HuC state accordingly after GuC fetch error
From: Michał Winiarski
Firmware "Selected" state is a transient state - we don't expect to see
it after finishing driver probe, we even have asserts sprinkled over
i915 to confirm whether that's the case.
Unfortunately - we don't handle the transition out of "Selected" in case
of GuC fetch error, leading those asserts to fire when calling
"intel_huc_is_used()".
Reported-by: Marcin Bernatowicz
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Marcin Bernatowicz
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 1c2d6358826c..993e9755f317 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -267,8 +267,14 @@ static void __uc_fetch_firmwares(struct intel_uc *uc)
GEM_BUG_ON(!intel_uc_wants_guc(uc));
err = intel_uc_fw_fetch(&uc->guc.fw);
- if (err)
+ if (err) {
+ /* Make sure we transition out of transient "SELECTED" state */
+ if (intel_uc_wants_huc(uc))
+ intel_uc_fw_change_status(&uc->huc.fw,
+ INTEL_UC_FIRMWARE_ERROR);
+
return;
+ }
if (intel_uc_wants_huc(uc))
intel_uc_fw_fetch(&uc->huc.fw);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Unpin idle contexts from kswapd reclaim
== Series Details == Series: drm/i915/gem: Unpin idle contexts from kswapd reclaim URL : https://patchwork.freedesktop.org/series/79204/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18096_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18096_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18096_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18096_full: ### IGT changes ### Possible regressions * igt@kms_properties@crtc-properties-atomic: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-tglb7/igt@kms_propert...@crtc-properties-atomic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-tglb2/igt@kms_propert...@crtc-properties-atomic.html Known issues Here are the changes found in Patchwork_18096_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-queues-priority-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-glk4/igt@gem_exec_whis...@basic-queues-priority-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-glk4/igt@gem_exec_whis...@basic-queues-priority-all.html * igt@i915_selftest@live@execlists: - shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([i915#794]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl6/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-kbl4/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#198] / [i915#2110]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl7/igt@i915_selftest@m...@requests.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-skl8/igt@i915_selftest@m...@requests.html * igt@kms_color@pipe-a-gamma: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#93] / [i915#95]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl3/igt@kms_co...@pipe-a-gamma.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-kbl6/igt@kms_co...@pipe-a-gamma.html * igt@kms_cursor_legacy@pipe-a-forked-move: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1635] / [i915#95]) +15 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-apl1/igt@kms_cursor_leg...@pipe-a-forked-move.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-apl3/igt@kms_cursor_leg...@pipe-a-forked-move.html * igt@kms_flip@flip-vs-expired-vblank@b-edp1: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl8/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-skl3/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-tglb8/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-tglb3/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: [PASS][19] -> [DMESG-FAIL][20] ([i915#118] / [i915#95]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-glk2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18096/shard-glk9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-blt: - shard-snb: [PASS][21] -> [TIMEOUT][22] ([i915#1958] / [i915#2119]) +3 similar issues [21]: https://intel-gfx-ci.01.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ehl: Add new PCI ids (rev2)
== Series Details ==
Series: drm/i915/ehl: Add new PCI ids (rev2)
URL : https://patchwork.freedesktop.org/series/78910/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18100
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/index.html
Known issues
Here are the changes found in Patchwork_18100 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-tgl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-u2/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-whl-u: [PASS][7] -> [DMESG-WARN][8] ([i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [PASS][9] -> [DMESG-FAIL][10] ([i915#1748])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-gdg-551/igt@i915_selftest@l...@coherency.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@vgem_basic@setversion:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([i915#402]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@vgem_ba...@setversion.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-tgl-y/igt@vgem_ba...@setversion.html
Possible fixes
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@gem_mmap_...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][17] ([i915#95]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@kms_force_connector_basic@force-connector-state:
- {fi-tgl-dsi}: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][23] ([i915#62]) -> [SKIP][24]
([fdo#109271])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18100/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][26] ([i915#62] / [i915#92]) +8 similar issues
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix initial fb to use resource_size_t
== Series Details == Series: drm/i915/display: Fix initial fb to use resource_size_t URL : https://patchwork.freedesktop.org/series/79205/ State : success == Summary == CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18097_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18097_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_create@madvise: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-glk1/igt@gem_exec_cre...@madvise.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-glk3/igt@gem_exec_cre...@madvise.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / [i915#716]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl4/igt@gen9_exec_pa...@allowed-single.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-skl9/igt@gen9_exec_pa...@allowed-single.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#198] / [i915#2110]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl7/igt@i915_selftest@m...@requests.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-skl1/igt@i915_selftest@m...@requests.html * igt@kms_color@pipe-a-gamma: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#93] / [i915#95]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl3/igt@kms_co...@pipe-a-gamma.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-kbl7/igt@kms_co...@pipe-a-gamma.html * igt@kms_cursor_legacy@pipe-a-forked-move: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1635] / [i915#95]) +19 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-apl1/igt@kms_cursor_leg...@pipe-a-forked-move.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-apl2/igt@kms_cursor_leg...@pipe-a-forked-move.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-skl5/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl2/igt@kms_flip@flip-vs-susp...@c-dp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-kbl6/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-blt: - shard-snb: [PASS][15] -> [TIMEOUT][16] ([i915#1958] / [i915#2119]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-snb5/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-snb5/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-blt.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#49]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl6/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-wc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-skl7/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-wc.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl10/igt@kms_...@bpc-switch-dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-skl1/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane_alpha_blend@pipe-a-coverage-vs-premult-vs-constant: - shard-kbl: [PASS][21] -> [DMESG-FAIL][22] ([fdo#108145] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-kbl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html - shard-apl: [PASS][23] -> [DMESG-FAIL][24] ([fdo#108145] / [i915#1635] / [i915#95]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-apl3/igt@kms_plane_alpha_bl...@pipe-a-coverage-vs-premult-vs-constant.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18097/shard-apl3/igt@kms_plane_alpha_bl...@pipe-a
Re: [Intel-gfx] [PATCH v2] drm/i915/ehl: Add new PCI ids
On Tue, Jul 07, 2020 at 01:45:30PM -0700, José Roberto de Souza wrote: > Two new PCI ids added to ehl. > > v2: added two additional PCI ids > > BSpec: 29153 > Cc: Matt Roper > Cc: Anusha Srivatsa > Signed-off-by: José Roberto de Souza Reviewed-by: Matt Roper > --- > include/drm/i915_pciids.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > index bc989de2aac2..d6cb28992ba0 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -588,7 +588,11 @@ > INTEL_VGA_DEVICE(0x4551, info), \ > INTEL_VGA_DEVICE(0x4541, info), \ > INTEL_VGA_DEVICE(0x4E71, info), \ > + INTEL_VGA_DEVICE(0x4557, info), \ > + INTEL_VGA_DEVICE(0x4555, info), \ > INTEL_VGA_DEVICE(0x4E61, info), \ > + INTEL_VGA_DEVICE(0x4E57, info), \ > + INTEL_VGA_DEVICE(0x4E55, info), \ > INTEL_VGA_DEVICE(0x4E51, info) > > /* TGL */ > -- > 2.27.0 > -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-fence annotations, round 3 (rev2)
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2ef2cbad3c3f dma-fence: basic lockdep annotations
-:23: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e91498589746
("locking/lockdep/selftests: Add mixed read-write ABBA tests")'
#23:
commit e91498589746065e3ae95d9a00b068e525eec34f
-:97: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e966eaeeb623 ("locking/lockdep:
Remove the cross-release locking checks")'
#97:
commit e966eaeeb623f09975ef362c2866fae6f86844f9
-:103: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#103:
This code (CONFIG_LOCKDEP_CROSSRELEASE=y and
CONFIG_LOCKDEP_COMPLETIONS=y),
-:303: ERROR:IN_ATOMIC: do not use in_atomic in drivers
#303: FILE: drivers/dma-buf/dma-fence.c:228:
+ if (in_atomic())
-:341: CHECK:LINE_SPACING: Please don't use multiple blank lines
#341: FILE: drivers/dma-buf/dma-fence.c:266:
+
+
-:390: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#390: FILE: include/linux/dma-fence.h:368:
+}
+static inline void dma_fence_end_signalling(bool cookie) {}
-:396: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 3 errors, 2 warnings, 2 checks, 217 lines checked
161956239d13 dma-fence: prime lockdep annotations
-:31: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 23b68395c7c7 ("mm/mmu_notifiers:
add a lockdep map for invalidate_range_start/end")'
#31:
commit 23b68395c7c78a764e8963fc15a7cfd318bf187f
-:193: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 91 lines checked
8b75e6b6b1b6 dma-buf.rst: Document why idenfinite fences are a bad idea
-:149: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 105 lines checked
5fad761a1004 drm/vkms: Annotate vblank timer
-:59: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 25 lines checked
92b268014731 drm/vblank: Annotate with dma-fence signalling section
-:71: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 38 lines checked
cf8a240564b5 drm/amdgpu: add dma-fence annotations to atomic commit path
-:52: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 24 lines checked
7a522c30b416 drm/komdea: Annotate dma-fence critical section in commit path
-:46: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 15 lines checked
c378cbda4b96 drm/malidp: Annotate dma-fence critical section in commit path
-:38: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 15 lines checked
4507fb407ce9 drm/atmel: Use drm_atomic_helper_commit
-:213: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 170 lines checked
bbe90243440b drm/imx: Annotate dma-fence critical section in commit path
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 21a01abbe32a ("drm/atomic: Fix
freeing connector/plane state too early by tracking commits, v3.")'
#14:
commit 21a01abbe32a3cbeb903378a24e504bfd9fe0648
-:50: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 14 lines checked
8d9019996f33 drm/omapdrm: Annotate dma-fence critical section in commit path
-:54: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 29 lines checked
e54ea8ce539b drm/rcar-du: Annotate dma-fence critical section in commit path
-:34: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
b6a053a9563c drm/tegra: Annotate dma-fence critical section in commit path
-:34: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
c4c8e32708f2 drm/tidss: Annotate dma-fence critical section in commit path
-:40: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dma-fence annotations, round 3 (rev2)
== Series Details == Series: dma-fence annotations, round 3 (rev2) URL : https://patchwork.freedesktop.org/series/79212/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int [addressable] [usertype] ulClockParams +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 [usertype] +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type in assignment (different base types) +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many warnings +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to restricted __le32 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to restricted __le16 +drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:598:21: warning: cast to restricted __le16 +d
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix initial fb to use resource_size_t (rev2)
== Series Details == Series: drm/i915/display: Fix initial fb to use resource_size_t (rev2) URL : https://patchwork.freedesktop.org/series/79205/ State : success == Summary == CI Bug Log - changes from CI_DRM_8710_full -> Patchwork_18098_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18098_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@processes: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl3/igt@gem_ctx_persiste...@processes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-skl10/igt@gem_ctx_persiste...@processes.html * igt@gem_exec_balancer@sliced: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#1936] / [i915#1958] / [i915#2119]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-tglb8/igt@gem_exec_balan...@sliced.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-tglb1/igt@gem_exec_balan...@sliced.html * igt@gem_exec_reloc@basic-gtt-cpu-noreloc: - shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#2119]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-tglb8/igt@gem_exec_re...@basic-gtt-cpu-noreloc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-tglb1/igt@gem_exec_re...@basic-gtt-cpu-noreloc.html * igt@gen9_exec_parse@allowed-all: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#1436] / [i915#716]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl7/igt@gen9_exec_pa...@allowed-all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-kbl3/igt@gen9_exec_pa...@allowed-all.html * igt@kms_big_fb@x-tiled-32bpp-rotate-180: - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-snb4/igt@kms_big...@x-tiled-32bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-snb2/igt@kms_big...@x-tiled-32bpp-rotate-180.html * igt@kms_color@pipe-a-gamma: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#93] / [i915#95]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-kbl3/igt@kms_co...@pipe-a-gamma.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-kbl1/igt@kms_co...@pipe-a-gamma.html * igt@kms_cursor_legacy@pipe-b-torture-move: - shard-iclb: [PASS][13] -> [DMESG-WARN][14] ([i915#128]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-iclb6/igt@kms_cursor_leg...@pipe-b-torture-move.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-iclb8/igt@kms_cursor_leg...@pipe-b-torture-move.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html * igt@kms_flip@flip-vs-suspend@a-edp1: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +6 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-skl6/igt@kms_flip@flip-vs-susp...@a-edp1.html * igt@kms_flip_tiling@flip-x-tiled: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#1635] / [i915#95]) +12 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-apl3/igt@kms_flip_til...@flip-x-tiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-apl1/igt@kms_flip_til...@flip-x-tiled.html * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-blt: - shard-snb: [PASS][23] -> [TIMEOUT][24] ([i915#1958] / [i915#2119]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8710/shard-snb5/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-blt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18098/shard-snb2/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-blt.html * igt@kms_frontbuffe
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-fence annotations, round 3 (rev2)
== Series Details ==
Series: dma-fence annotations, round 3 (rev2)
URL : https://patchwork.freedesktop.org/series/79212/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8711 -> Patchwork_18101
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/index.html
Known issues
Here are the changes found in Patchwork_18101 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar
issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-tgl-y/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_module_load@reload:
- fi-kbl-soraka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +2 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-kbl-soraka/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-whl-u: [PASS][5] -> [DMESG-WARN][6] ([i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
- fi-byt-j1900: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Possible fixes
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@gem_mmap_...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [DMESG-WARN][17] ([i915#95]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
- fi-bsw-kefka: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8711/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18101/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][25] ([i915#1982]) -> [PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DR
