On 3/10/2020 5:19 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Certain workloads need the ability to disable preemption completely so
allow them to do that by whitelisting GEN8_CS_CHICKEN1.
Signed-off-by: Tvrtko Ursulin
Cc: Michal Mrozek
Cc: Tony Ye
Cc: Rafael Antognolli
Cc: Jason
On Wed, Mar 11, 2020 at 9:52 AM Christian König
wrote:
>
> We should be able to do this now after checking all the prerequisites.
>
> v2: fix entrie count in the sgt
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 56 ---
>
This is the third and final part of my series to start supporting P2P with
DMA-buf.
The implementation is straight forward, apart from a helper to aid constructing
scatterlists without having struct pages we only add a new flag indicating that
an DMA-buf importer can handle peer2peer.
The
Note if a buffer was imported using peer2peer.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index
This can be used by drivers to setup P2P DMA between device
memory which is not backed by struct pages.
The drivers of the involved devices are responsible for
setting up and tearing down DMA addresses as necessary
using dma_map_resource().
The page pointer is set to NULL and only the DMA
Check if we can do peer2peer on the PCIe bus.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index
Am 11.03.20 um 15:04 schrieb Jason Gunthorpe:
On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote:
Check if we can do peer2peer on the PCIe bus.
Signed-off-by: Christian König
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4
1 file changed, 4 insertions(+)
diff --git
Add a peer2peer flag noting that the importer can deal with device
resources which are not backed by pages.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 2 ++
include/linux/dma-buf.h | 10 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c
We should be able to do this now after checking all the prerequisites.
v2: fix entrie count in the sgt
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 56 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 12 ++-
Importing should work out of the box.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index ffeb20f11c07..aef12ee2f1e3
On Wed, 11 Mar 2020, Jani Nikula wrote:
On Mon, 09 Mar 2020, Jani Nikula wrote:
Please ignore this, I seem to have some smtp trouble which fails some of
tha patches. This will be incomplete.
Wambui, I'll resend this later.
Okay, I sent them with the same message-ids, so the patches
Am 11.03.20 um 15:38 schrieb Jason Gunthorpe:
On Wed, Mar 11, 2020 at 03:33:01PM +0100, Christian König wrote:
Am 11.03.20 um 15:04 schrieb Jason Gunthorpe:
On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote:
Check if we can do peer2peer on the PCIe bus.
Signed-off-by: Christian
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Mark up racy reads for
intel_context.inflight (rev2)
URL : https://patchwork.freedesktop.org/series/74520/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8110_full -> Patchwork_16906_full
> -Original Message-
> From: Intel-gfx On Behalf Of Bob
> Paauwe
> Sent: Thursday, March 5, 2020 11:30 PM
> To: Patchwork
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Adding YUV444 packed format
> support
> for skl+ (rev4)
>
> On Sat, 29
BAT failure is due to rather funny issue, with plane states, this is a true
failure however
apparently now the reason is identified. The old code was lacking a proper
plane state enumeration, which caused an issue once SAGV changes forced it to
be executed in other place.
Best Regards,
== Series Details ==
Series: drm/i915: Tweak scheduler's kick_submission() (rev2)
URL : https://patchwork.freedesktop.org/series/74279/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8110_full -> Patchwork_16905_full
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Pull checking rps->pm_events
under the irq_lock
URL : https://patchwork.freedesktop.org/series/74574/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8117 -> Patchwork_16924
For conveniences of callers that just want to use an i915_active to
track a wide array of concurrent timelines, wrap the base i915_active
struct inside a kref. This i915_active will self-destruct after use.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real
Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To
avoid the sparse warning for using the RCU pointer directly, we have to
cast away the __rcu annotation. However, we don't need to use void*
everywhere and can stick to the dma_fence*.
Signed-off-by: Chris Wilson
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed and as this wait may be on a
distinct
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
include/uapi/drm/i915_drm.h| 7 ---
2 files changed, 11
Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Signed-off-by: Chris Wilson
---
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
v2: Also measure throughput using only one thread.
Signed-off-by: Chris Wilson
---
A few very simple testcases to exercise the dma-fence-chain API.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-chain.c | 713 +++
3 files changed, 716
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris
== Series Details ==
Series: drm/i915: Extend i915_request_await_active to use all timelines
URL : https://patchwork.freedesktop.org/series/74573/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8117 -> Patchwork_16923
When applying the context-barrier, we only care about the current
engines, as the next set of engines will be naturally after the barrier.
So we can skip holding the ctx->engines_mutex while constructing the
request by taking a sneaky reference to the i915_gem_engines instead.
Signed-off-by:
Quoting Chris Wilson (2020-03-11 12:59:03)
> +static inline struct i915_gem_engines *
> +__context_engines_await(const struct i915_gem_context *ctx)
> +{
> + struct i915_gem_engines *engines;
> +
> + rcu_read_lock();
> + do {
> + engines =
Op 11-03-2020 om 13:49 schreef Chris Wilson:
> When applying the context-barrier, we only care about the current
> engines, as the next set of engines will be naturally after the barrier.
> So we can skip holding the ctx->engines_mutex while constructing the
> request by taking a sneaky reference
When applying the context-barrier, we only care about the current
engines, as the next set of engines will be naturally after the barrier.
So we can skip holding the ctx->engines_mutex while constructing the
request by taking a sneaky reference to the i915_gem_engines instead.
Signed-off-by:
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev3)
URL : https://patchwork.freedesktop.org/series/74461/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8117 -> Patchwork_16922
Summary
---
**FAILURE**
== Series Details ==
Series: list: Prevent compiler reloads inside 'safe' list iteration
URL : https://patchwork.freedesktop.org/series/74495/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8108_full -> Patchwork_16903_full
When applying the context-barrier, we only care about the current
engines, as the next set of engines will be naturally after the barrier.
So we can skip holding the ctx->engines_mutex while constructing the
request by taking a sneaky reference to the i915_gem_engines instead.
Signed-off-by:
On Tue, Mar 10, 2020 at 02:41:54PM -0700, Francisco Jerez wrote:
> +static void cpu_response_frequency_qos_apply(struct pm_qos_request *req,
> + enum pm_qos_req_action action,
> + s32 value)
> +{
> + int ret =
In most cases, we can walk the array of engines underneath the context
using plain RCU protection -- we've set a flag on the context, and just
need to propagate that flag to the current engines, if those engines
are replaced as we do so, the new engines will get the new flag.
However, in one
Hey,
On Tue, 10 Mar 2020, Takashi Iwai wrote:
> On Tue, 10 Mar 2020 19:25:22 +0100, Ville Syrjälä wrote:
>> On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
>>> One problematic scenario that this doesn't cover:
>>> - a single display is used (at low cdclk), and
>>> - audio block
Hi Tvrtko,
On Tue, Mar 10, 2020 at 02:29:58PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use new common helper intel_gt_show_forcewake from both old and new
> debugfs code.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Andi Shyti
Thanks,
Reviewed-by: Andi Shyti
Andi
Chris Wilson writes:
> [11057.642683] BUG: KCSAN: data-race in i915_gem_mmap [i915] /
> singleton_release [i915]
> [11057.642717]
> [11057.642740] write (marked) to 0x8881f24471a0 of 8 bytes by task 44668
> on cpu 2:
> [11057.643162] singleton_release+0x38/0x60 [i915]
> [11057.643192]
== Series Details ==
Series: drm/i915/debugfs: print more workaround registers
URL : https://patchwork.freedesktop.org/series/74571/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8116 -> Patchwork_16921
Summary
---
On Sat, Feb 15, 2020 at 01:56:27AM +0800, Kai-Heng Feng wrote:
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945]
Chris Wilson writes:
> Record the initial active element we use when building the next ELSP
> submission, so that we can compare against it latter to see if there's
> no change.
>
> Fixes: 44d0a9c05bc0 ("drm/i915/execlists: Skip redundant resubmission")
> Signed-off-by: Chris Wilson
Chris Wilson writes:
> The residual w/a batch is casing system instablity on Ivybridge and
> Baytrail under some workloads, so disable until resolved.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/1405
> Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
>
On Mon, 09 Mar 2020, Jani Nikula wrote:
> Please ignore this, I seem to have some smtp trouble which fails some of
> tha patches. This will be incomplete.
>
> Wambui, I'll resend this later.
Okay, I sent them with the same message-ids, so the patches amended this
beginning of the series.
I
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
v2: Also measure throughput using only one thread.
Signed-off-by: Chris Wilson
---
On Thu, 05 Mar 2020, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (rev2)
> URL : https://patchwork.freedesktop.org/series/74100/
> State : failure
>
> == Summary ==
>
> Applying: drm/i915/dp: Add dpcd link_rate quirk for Apple
The residual w/a batch is casing system instablity on Ivybridge and
Baytrail under some workloads, so disable until resolved.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1405
Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: Chris Wilson
Cc: Mika
Quoting Tvrtko Ursulin (2020-03-11 10:00:41)
>
> On 10/03/2020 22:26, Chris Wilson wrote:
> > Quoting Francisco Jerez (2020-03-10 21:41:55)
> >> static inline void
> >> @@ -2386,6 +2397,9 @@ static void process_csb(struct intel_engine_cs
> >> *engine)
> >> /* port0
On 10/03/2020 20:12, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-03-10 20:04:23)
On 10/03/2020 18:32, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-03-09 18:31:25)
+static ssize_t
+show_client_busy(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct
== Series Details ==
Series: drm/i915: Enable non-contiguous pipe fusing
URL : https://patchwork.freedesktop.org/series/74570/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8113 -> Patchwork_16920
Summary
---
On 10/03/2020 22:26, Chris Wilson wrote:
Quoting Francisco Jerez (2020-03-10 21:41:55)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index b9b3f78f1324..a5d7a80b826d 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++
Hi
Am 02.03.20 um 23:26 schrieb Daniel Vetter:
> The cleanup here is somewhat tricky, since we can't tell apart the
> allocated minor index from 0. So register a cleanup action first, and
> if the index allocation fails, unregister that cleanup action again to
> avoid bad mistakes.
>
> The kdev
Am 11.03.20 um 10:07 schrieb Thomas Zimmermann:
> Hi Daniel
>
> Am 02.03.20 um 23:25 schrieb Daniel Vetter:
>> We have lots of these. And the cleanup code tends to be of dubious
>> quality. The biggest wrong pattern is that developers use devm_, which
>> ties the release action to the
== Series Details ==
Series: drm/i915/gt: Use scnprintf() for avoiding potential buffer overflow
URL : https://patchwork.freedesktop.org/series/74562/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16919
Hi
Am 02.03.20 um 23:26 schrieb Daniel Vetter:
> Well for the simple stuff at least, vblank, gem and minor cleanup I
> want to further split up as a demonstration.
>
> v2: We need to clear drm_device->dev otherwise the debug drm printing
> after our cleanup hook (e.g. in drm_manged_release) will
We [will] expose various per-engine scheduling controls. One of which,
'preempt_timeout_ms', defines how we wait for a preemption request to be
honoured by the currently executing context. If it fails to relieve the
GPU within the required timeout, the engine is reset and the miscreant
forcibly
Quite frequently we want to execute on one precise engine, so add a
convenience routine to create a context that contains only that engine
in the default [0] slot.
Signed-off-by: Chris Wilson
---
lib/i915/gem_context.c | 64 +++---
lib/i915/gem_context.h | 2
Simplify testing sysfs/engines by providing a convenience routine that
iterates over each engine, calling a igt_dynamic routine.
Signed-off-by: Chris Wilson
---
lib/i915/gem_engine_topology.c | 48 ++
lib/i915/gem_engine_topology.h | 3 +++
2 files changed, 51
We [will] expose various per-engine scheduling controls. One of which,
'heartbeat_duration_ms', defines how often we send a heartbeat down the
engine to check upon the health of the engine. If a heartbeat does not
complete within the interval (or two), the engine is declared hung.
Signed-off-by:
We [will] expose various per-engine scheduling controls. One of which,
'timeslice_duration_ms', defines the scheduling quantum. If a context
exhausts its timeslice, it will be preempted in favour of running one of
its compatriots.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources
Hi Chris,
> -Original Message-
> From: Chris Wilson
> Sent: Wednesday, March 11, 2020 5:25 PM
> To: Liu, Chuansheng ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/debugfs: print more workaround
> registers
>
> Quoting Chuansheng Liu (2020-03-11
Record the initial active element we use when building the next ELSP
submission, so that we can compare against it latter to see if there's
no change.
Fixes: 44d0a9c05bc0 ("drm/i915/execlists: Skip redundant resubmission")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 32
Avoid angering kcsan by serialising the read of the pm_events with the
write in rps_disable_interrupts.
[ 6268.713419] BUG: KCSAN: data-race in intel_rps_park [i915] / rps_work [i915]
[ 6268.713437]
[ 6268.713449] write to 0x8881eda8efac of 4 bytes by task 1127 on cpu 3:
[ 6268.713680]
[11057.642683] BUG: KCSAN: data-race in i915_gem_mmap [i915] /
singleton_release [i915]
[11057.642717]
[11057.642740] write (marked) to 0x8881f24471a0 of 8 bytes by task 44668 on
cpu 2:
[11057.643162] singleton_release+0x38/0x60 [i915]
[11057.643192] __fput+0x160/0x3c0
[11057.643217]
Quoting Chuansheng Liu (2020-03-11 08:47:04)
> In the node i915_wa_registers, we could print out
> more information with whitelist, GT workaround and
> engine workaround.
Who's the consumer? We've stopped using this file in igt.
-Chris
___
Intel-gfx
We need to start passing memory latency as a
parameter when calculating plane wm levels,
as latency can get changed in different
circumstances(for example with or without SAGV).
So we need to be more flexible on that matter.
v2: Changed latency type from u32 to unsigned int(Ville Syrjälä)
Extend i915_request_await_active() to be able to asynchronously wait on
all the tracked timelines simultaneously.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 77 +-
drivers/gpu/drm/i915/i915_active.h | 8 +++-
== Series Details ==
Series: series starting with [v6,1/2] drm/edid: Name the detailed monitor range
flags
URL : https://patchwork.freedesktop.org/series/74541/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16918
Am 02.03.20 um 23:26 schrieb Daniel Vetter:
> We need to add a drmm_kstrdup for this, but let's start somewhere.
>
> This is not exactly perfect onion unwinding, but it's jsut a kfree so
> doesn't really matter at all.
>
> Signed-off-by: Daniel Vetter
Acked-by: Thomas Zimmermann
> ---
>
Currently intel_can_enable_sagv function contains
a mix of workarounds for different platforms
some of them are not valid for gens >= 11 already,
so lets split it into separate functions.
v2:
- Rework watermark calculation algorithm to
attempt to calculate Level 0 watermark
with
== Series Details ==
Series: drm/i915: Get rid of silly void* from MST code
URL : https://patchwork.freedesktop.org/series/74539/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16916
Summary
---
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> A few things:
> - Update the example driver in the documentation.
> - We can drop the old kfree in drm_dev_release.
> - Add a WARN_ON check in drm_dev_register to make sure everyone calls
> drmm_add_final_kfree and there's no leaks.
>
>
== Series Details ==
Series: drm/i915/gem: Mark up the racy read of the mmap_singleton
URL : https://patchwork.freedesktop.org/series/74531/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16914
Summary
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
<...>
> +
> +int __drmm_add_action(struct drm_device *dev,
> + drmres_release_t action,
> + void *data, const char *name)
> +{
> + struct drmres *dr;
> + void **void_ptr;
> +
> + dr = alloc_dr(action,
== Series Details ==
Series: drm/i915: Remove debugfs i915_drpc_info and i915_forcewake_domains
URL : https://patchwork.freedesktop.org/series/74529/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16913
== Series Details ==
Series: drm/i915/gen12: Disable preemption timeout (rev2)
URL : https://patchwork.freedesktop.org/series/74526/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16912
Summary
---
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> With this we can drop the final kfree from the release function.
>
> v2: We need drm_dev_put to unroll the driver creation (once
> drm_dev_init and drmm_add_final_kfree suceeded), otherwise
> the drmm_ magic doesn't happen.
>
> v3: Actually squash
== Series Details ==
Series: drm/i915: Add missing HDMI audio pixel clocks for gen12 (rev4)
URL : https://patchwork.freedesktop.org/series/72617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16911
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> I also did a full review of all callers, and only the xen driver
> forgot to call drm_dev_put in the failure path. Fix that up too.
>
> v2: I noticed that xen has a drm_driver.release hook, and uses
> drm_dev_alloc(). We need to remove the kfree
== Series Details ==
Series: drm/i915/execlists: Track active elements during dequeue (rev2)
URL : https://patchwork.freedesktop.org/series/74524/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16910
Hi Daniel
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> We have lots of these. And the cleanup code tends to be of dubious
> quality. The biggest wrong pattern is that developers use devm_, which
> ties the release action to the underlying struct device, whereas
> all the userspace visible stuff
== Series Details ==
Series: DP Phy compliance auto test (rev6)
URL : https://patchwork.freedesktop.org/series/71121/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16909
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/gt: Pull checking rps->pm_events under the irq_lock (rev2)
URL : https://patchwork.freedesktop.org/series/74510/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16908
== Series Details ==
Series: drm/i915: Consolidate forcewake status display
URL : https://patchwork.freedesktop.org/series/74522/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8112 -> Patchwork_16907
Summary
---
In the node i915_wa_registers, we could print out
more information with whitelist, GT workaround and
engine workaround.
In addition, fix the warning by checkpatch.pl:
WARNING: Prefer seq_puts to seq_printf
Signed-off-by: Chuansheng Liu
---
drivers/gpu/drm/i915/i915_debugfs.c | 60
Allow 3-display pipes SKU system with any combination
in INTEL_INFO pipe mask.
B.Spec:50075
changes since RFC:
- using intel_pipe_mask_is_valid() function to check integrity of
pipe_mask. [Ville]
v2:
- simplify condition in intel_pipe_mask_is_valid(). [Ville]
v3:
- removed non-contiguous pipe
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Mark up racy reads for
intel_context.inflight (rev2)
URL : https://patchwork.freedesktop.org/series/74520/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8110 -> Patchwork_16906
== Series Details ==
Series: drm/i915: Tweak scheduler's kick_submission() (rev2)
URL : https://patchwork.freedesktop.org/series/74279/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8110 -> Patchwork_16905
Summary
---
== Series Details ==
Series: drm/i915: Defer semaphore priority bumping to a workqueue
URL : https://patchwork.freedesktop.org/series/74496/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8110 -> Patchwork_16904
Summary
Hi Daniele,
> > > > > > > Quoting Andi Shyti (2020-03-06 23:03:44)
> > > > > > > > -void debugfs_gt_register_files(struct intel_gt *gt,
> > > > > > > > - struct dentry *root,
> > > > > > > > - const struct debugfs_gt_file
> > > > > > > >
On Tue, 10 Mar 2020, Wambui Karuga wrote:
> Since commit 987d65d01356 (drm: debugfs: make
> drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
> fails and should return void. Therefore, remove its use as the
> return value of debugfs_init() functions and have the functions
== Series Details ==
Series: list: Prevent compiler reloads inside 'safe' list iteration
URL : https://patchwork.freedesktop.org/series/74495/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8108 -> Patchwork_16903
Summary
== Series Details ==
Series: drm/i915/tgl: WaEnablePreemptionGranularityControlByUMD
URL : https://patchwork.freedesktop.org/series/74494/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8108 -> Patchwork_16902
Summary
Hi Tvrtko,
On Tue, Mar 10, 2020 at 04:47:33PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> The two files have been duplicated under the gt/ subdir and since there
> are not apparent users looking for them at the old location lets simply
> remove them and duplicated code.
>
>
== Series Details ==
Series: drm/i915/gt: Use scnprintf() for avoiding potential buffer overflow
URL : https://patchwork.freedesktop.org/series/74562/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
00261fad413a drm/i915/gt: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +++---
1 file changed, 3
101 - 199 of 199 matches
Mail list logo
