Hi,
On 20-10-2019 20:19, Hans de Goede wrote:
Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
vblank waits"), I am seeing an ugly colored flash of the first few display
lines on 2 Cherry Trail devices when the gamma table gets set for the first
time. A blue flash on a
The actual conditions are that we know the GPU is not accessing the
context, and we hold a pin on the context image to allow CPU access. We
used a fake lock on ce->pin_mutex so that we could try and use lockdep
to assert that access is serialised, but the various different
hardirq/softirq contexts
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure. Later
Normally, we rely on our hangcheck to prevent persistent batches from
hogging the GPU. However, if the user disables hangcheck, this mechanism
breaks down. Despite our insistence that this is unsafe, the users are
equally insistent that they want to use endless batches and will disable
the hangchec
Separate each object class into a separate lock type to avoid lockdep
cross-contamination between paths (i.e. userptr!).
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 3 ++-
d
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit
Both routines operate local to the intel_gt, so pass it along as the
object to work on.
Signed-off-by: Chris Wilson
---
.../drm/i915/gem/selftests/i915_gem_context.c | 30 +++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_context.c| 4 +-
Replace sampling the engine state every so often with a periodic
heartbeat request to measure the health of an engine. This is coupled
with the forced-preemption to allow long running requests to survive so
long as they do not block other users.
The heartbeat interval can be adjusted per-engine us
The parallel switch test has an underlying assumption that its requests
are executed in order of submission, which is only true if the backend
manages to keep up. Ensure the order of execution matches the submission
order by explicit dependencies and so when we wait on the last request,
we know we
Probe the mocs registers for new contexts and across GPU resets. Similar
to intel_workarounds, we have tables of what register values we expect
to see, so verify that user contexts are affected by them. In the
future, we should add tests similar to intel_sseu to cover dynamic
reconfigurations.
Sig
If we change the priority of the active context, then it has no impact
on the decision of whether to preempt the active context -- we don't
preempt the context with itself. In this situation, we elide the tasklet
rescheduling and should *not* be marking up the queue_priority_hint as
that may mask a
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to ensure idle barriers are
immediately flushe
Execlists uses a scheduling quantum (a timeslice) to alternate execution
between ready-to-run contexts of equal priority. This ensures that all
users (though only if they of equal importance) have the opportunity to
run and prevents livelocks where contexts may have implicit ordering due
to userspa
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 14 +
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 1 +
Use the per-engine sysfs directory to let userspace discover the
mmio_base of each engine. Prior to recent generations, the user
accessible registers on each engine are at a fixed offset relative to
each engine -- but require absolute addressing. As the absolute address
depends on the actual physic
If the preempted context takes too long to relinquish control, e.g. it
is stuck inside a shader with arbitration disabled, evict that context
with an engine reset. This ensures that preemptions are reasonably
responsive, providing a tighter QoS for the more important context at
the cost of flagging
On schedule-out (CS completion) of a banned context, scrub the context
image so that we do not replay the active payload. The intent is that we
skip banned payloads on request submission so that the timeline
advancement continues on in the background. However, if we are returning
to a preempted req
Quoting Zhenyu Wang (2019-10-21 06:37:24)
> On 2019.10.16 19:39:02 +0100, Chris Wilson wrote:
> > Stop trying to escape out of the gvt layer to find the engine that we
> > initially setup for use with gvt. Record the engines during initialisation
> > and use them henceforth.
> >
> > add/remove: 1/
Hi,
On 18/10/2019 23:11, Sean Paul wrote:
On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen wrote:
Hi Sean,
On 17/10/2019 22:26, Sean Paul wrote:
concern for those. The omap OMAP_BO_MEM_* changes though I don't think have
really reached non-TI eyes. There's no link in the commit message to a
== Series Details ==
Series: series starting with [01/16] drm/i915: Don't set queue_priority_hint if
we don't kick the submission
URL : https://patchwork.freedesktop.org/series/68295/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
48cdac321482 drm/i915: Don't set queue_priority
== Series Details ==
Series: series starting with [01/16] drm/i915: Don't set queue_priority_hint if
we don't kick the submission
URL : https://patchwork.freedesktop.org/series/68295/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Don't set
== Series Details ==
Series: series starting with [01/16] drm/i915: Don't set queue_priority_hint if
we don't kick the submission
URL : https://patchwork.freedesktop.org/series/68295/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7138 -> Patchwork_14900
==
On Mon, 21 Oct 2019 13:59:23 +0800
Jason Wang wrote:
> On 2019/10/18 下午10:20, Cornelia Huck wrote:
> > On Thu, 17 Oct 2019 18:48:35 +0800
> > Jason Wang wrote:
> >
> >> This patch introduces a new mdev transport for virtio. This is used to
> >> use kernel virtio driver to drive the mediated de
Chris Wilson writes:
> If we change the priority of the active context, then it has no impact
> on the decision of whether to preempt the active context -- we don't
> preempt the context with itself. In this situation, we elide the tasklet
> rescheduling and should *not* be marking up the queue_p
Quoting Mika Kuoppala (2019-10-21 10:49:14)
> Chris Wilson writes:
>
> > If we change the priority of the active context, then it has no impact
> > on the decision of whether to preempt the active context -- we don't
> > preempt the context with itself. In this situation, we elide the tasklet
> >
Several tests depend upon the implicit engine->mmio_base but have no
means of determining the physical layout. Since the kernel has started
providing this information, start putting it to use.
Signed-off-by: Chris Wilson
---
lib/i915/gem_engine_topology.c | 84 ++
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-10-21 10:49:14)
>> Chris Wilson writes:
>>
>> > If we change the priority of the active context, then it has no impact
>> > on the decision of whether to preempt the active context -- we don't
>> > preempt the context with itself. In this situa
On 10/17/2019 8:08 PM, Tvrtko Ursulin wrote:
On 17/10/2019 14:53, Animesh Manna wrote:
On 10/17/2019 6:39 PM, Tvrtko Ursulin wrote:
On 17/10/2019 13:52, Animesh Manna wrote:
On 10/17/2019 2:05 PM, Tvrtko Ursulin wrote:
On 22/08/2019 13:09, Chris Wilson wrote:
Quoting Animesh Manna (2019-0
On 2019/10/21 下午5:36, Cornelia Huck wrote:
On Mon, 21 Oct 2019 13:59:23 +0800
Jason Wang wrote:
On 2019/10/18 下午10:20, Cornelia Huck wrote:
On Thu, 17 Oct 2019 18:48:35 +0800
Jason Wang wrote:
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio drive
Quoting Animesh Manna (2019-10-21 11:11:04)
>
>
> On 10/17/2019 8:08 PM, Tvrtko Ursulin wrote:
> >
> > On 17/10/2019 14:53, Animesh Manna wrote:
> >> On 10/17/2019 6:39 PM, Tvrtko Ursulin wrote:
> >>> On 17/10/2019 13:52, Animesh Manna wrote:
> On 10/17/2019 2:05 PM, Tvrtko Ursulin wrote:
>
Hi Chris,
On Thursday, October 10, 2019 4:23:16 PM CEST Chris Wilson wrote:
> No good reason why we must always use a static ringsize, so let
> userspace select one during construction.
I've heard from UMD people they like this solution :-)
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
>
This is really just an alias of mmap_gtt. The 'mmap offset' nomenclature
comes from the value returned by this ioctl which is the offset into the
device fd which userpace uses with mmap(2).
mmap_gtt was our initial mmap_offset implementation, this extends
our CPU mmap support to allow additional f
Have i915 replace the core drm_gem_mmap implementation to overcome its
limitation in having only a single mmap offset node per gem object.
This change allows us to have multiple mmap offsets per object and
enables a mmapping instance to use unique fault-handlers per user vma.
This allows i915 to s
No reason for sticking to GTT mmaps now we have CPU WC mmaps via
our new mmap offset plumbing.
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 10 ++
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h
From: Daniele Ceraolo Spurio
The following patches in the series will use it to avoid certain
operations when aperture is not available in HW.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drive
Fault handler to handle missing pages for shmem-backed objects.
v2: bail out of inserting PTEs when failing to insert the
fault address
v3: has struct page check
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1
Several tests depend upon the implicit engine->mmio_base but have no
means of determining the physical layout. Since the kernel has started
providing this information, start putting it to use.
Signed-off-by: Chris Wilson
---
lib/i915/gem_engine_topology.c | 84 ++
Some of the non-privileged registers are at the same offset on each
engine. We can improve our coverage for unknown HW layout by using the
reported engine->mmio_base for relative offsets.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_isolation.c | 160 -
1 fi
On Fri, 18 Oct 2019, Janusz Krzysztofik
wrote:
> Commit 2d6f6f359fd8 ("drm/i915: add i915_driver_modeset_remove()")
Please look at that commit and explain to me how it impacts anything
about intel_irq_uninstall().
BR,
Jani.
> claimed removal of asymmetry in probe() and remove() calls, however
On Mon, 21 Oct 2019, Jani Nikula wrote:
> On Fri, 18 Oct 2019, Janusz Krzysztofik
> wrote:
>> Commit 2d6f6f359fd8 ("drm/i915: add i915_driver_modeset_remove()")
>
> Please look at that commit and explain to me how it impacts anything
> about intel_irq_uninstall().
Seriously, why was this merged
On Mon, 21 Oct 2019, Jani Nikula wrote:
> On Mon, 21 Oct 2019, Jani Nikula wrote:
>> On Fri, 18 Oct 2019, Janusz Krzysztofik
>> wrote:
>>> Commit 2d6f6f359fd8 ("drm/i915: add i915_driver_modeset_remove()")
>>
>> Please look at that commit and explain to me how it impacts anything
>> about intel
== Series Details ==
Series: series starting with [1/5] drm/i915: Allow i915 to manage the vma
offset nodes instead of drm core
URL : https://patchwork.freedesktop.org/series/68301/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c3b8aae884d4 drm/i915: Allow i915 to manage the v
== Series Details ==
Series: series starting with [1/5] drm/i915: Allow i915 to manage the vma
offset nodes instead of drm core
URL : https://patchwork.freedesktop.org/series/68301/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7139 -> Patchwork_14901
Quoting Abdiel Janulgue (2019-10-21 11:48:10)
> +int
> +i915_gem_mmap_dumb(struct drm_file *file,
> + struct drm_device *dev,
> + u32 handle,
> + u64 *offset)
> +{
> + return __assign_gem_object_mmap_data(file, handle, I915_MMAP_TYPE_WC,
It sti
On Sat, Oct 19, 2019 at 12:20:18AM +0100, Chris Wilson wrote:
> Quoting Kumar Valsan, Prathap (2019-10-19 00:24:13)
> > On Fri, Oct 18, 2019 at 11:14:39PM +0100, Chris Wilson wrote:
> > > +static int check_l3cc_table(struct intel_engine_cs *engine,
> > > + const struct drm_i
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to ensure idle barriers are
immediately flushe
On Sun, Oct 20, 2019 at 08:19:33PM +0200, Hans de Goede wrote:
> Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
> vblank waits"), I am seeing an ugly colored flash of the first few display
> lines on 2 Cherry Trail devices when the gamma table gets set for the first
> ti
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in
Hi all,
Essentially just a resend of the latest revision, since the series is
stuck on the nouveau patch. Ilia tried it on an nv5 and it didn't explode,
but he noticed some instability. No call yet on whether that was just the
kernel upgrade of a few versions, or my patch.
So yeah I need to get s
We can't copy_*_user while holding reservations, that will (soon even
for nouveau) lead to deadlocks. And it breaks the cross-driver
contract around dma_resv.
Fix this by adding a slowpath for when we need relocations, and by
pushing the writeback of the new presumed offsets to the very end.
Asid
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.
Assuming I didn't screw up anything with my audit of course.
v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less wait optimization (Thomas)
- Use _lock_inte
== Series Details ==
Series: drm/i915/gt: Introduce barrier pulses along engines
URL : https://patchwork.freedesktop.org/series/68309/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
df6dba3e1726 drm/i915/gt: Introduce barrier pulses along engines
-:32: WARNING:FILE_PATH_CHANGES:
== Series Details ==
Series: drm/i915/gt: Introduce barrier pulses along engines
URL : https://patchwork.freedesktop.org/series/68309/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7141 -> Patchwork_14902
Summary
---
== Series Details ==
Series: dma_resv lockdep annotations/priming
URL : https://patchwork.freedesktop.org/series/68312/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a1051ffcc702 dma_resv: prime lockdep annotations
-:77: WARNING:BAD_SIGN_OFF: Duplicate signature
#77:
Cc: Rob H
On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen wrote:
>
> Hi,
>
> On 18/10/2019 23:11, Sean Paul wrote:
> > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen
> > wrote:
> >>
> >> Hi Sean,
> >>
> >> On 17/10/2019 22:26, Sean Paul wrote:
> >>
> >>> concern for those. The omap OMAP_BO_MEM_* changes th
== Series Details ==
Series: dma_resv lockdep annotations/priming
URL : https://patchwork.freedesktop.org/series/68312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7141 -> Patchwork_14903
Summary
---
**SUCCESS**
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to ensure idle barriers are
immediately flushe
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to ensure idle barriers are
immediately flushe
i915_active must track over any engine, so expand the selftest to
iterate over all uabi engines.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/selftests/i915_active.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i
== Series Details ==
Series: drm/i915/gt: Introduce barrier pulses along engines (rev3)
URL : https://patchwork.freedesktop.org/series/68309/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
420dc8e008a2 drm/i915/gt: Introduce barrier pulses along engines
-:32: WARNING:FILE_PATH_C
== Series Details ==
Series: drm/i915/gt: Introduce barrier pulses along engines (rev3)
URL : https://patchwork.freedesktop.org/series/68309/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7141 -> Patchwork_14904
Summary
---
On 10/21/19 4:50 PM, Daniel Vetter wrote:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
> really no business holding struct_mutex while doing copy_*_user. But
> I haven't checke
On Fri, Oct 18, 2019 at 08:20:44AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/aml: Allow SPT PCH for all AML devices (rev2)
> URL : https://patchwork.freedesktop.org/series/68176/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7125_full -> Pat
On 21/10/2019 17:21, Chris Wilson wrote:
i915_active must track over any engine, so expand the selftest to
iterate over all uabi engines.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/selftests/i915_active.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
== Series Details ==
Series: drm/i915/selftests: Use all physical engines for i915_active
URL : https://patchwork.freedesktop.org/series/68322/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7141 -> Patchwork_14905
Summary
-
On Fri, Oct 18, 2019 at 01:34:35AM -0700, Lisovskiy, Stanislav wrote:
> On Thu, 2019-10-17 at 14:53 -0700, James Ausmus wrote:
> > On Tue, Oct 15, 2019 at 04:50:12PM +0300, Stanislav Lisovskiy wrote:
> > > Currently intel_can_enable_sagv function contains
> > > a mix of workarounds for different pl
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to ensure idle barriers are
immediately flushe
ba6fa6e905d8fe81da4591d3e7a65878:
drm/i915: Update DRIVER_DATE to 20191021 (2019-10-21 12:56:07 +0300)
UAPI Changes:
- Introduce a versioning of the i915-perf uapi (Lionel)
- Add support for perf configuration queries (Lionel)
Allow li
With the last user, i915_vma_parked(), retired, there are no more users
of the per-gt pm notifications and we can remove the unused
infrastructure.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 25
drivers/gpu/drm/i915/gem
Currently even though i915_vma_parked() operates on a per-gt struct, it
is called from a global pm notify. This oddity was only because the long
term plan is to decouple the vma cache from the pm notification, but
right now the oddity stands out like a sore thumb!
Suggested-by: Tvrtko Ursulin
Sig
> -Original Message-
> From: Jason Wang
> Sent: Thursday, October 17, 2019 5:49 AM
> To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> kwankh.
> -Original Message-
> From: kvm-ow...@vger.kernel.org On Behalf
> Of Jason Wang
> Sent: Thursday, October 17, 2019 5:49 AM
> To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibi
The attachment list is now protected by the dma_resv object.
So we can drop holding this lock to allow concurrent attach
and detach operations.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/dma-buf/dma-bu
> -Original Message-
> From: Jason Wang
> Sent: Thursday, October 17, 2019 5:49 AM
> To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> kwankh.
> -Original Message-
> From: Ville Syrjälä
> Sent: Monday, October 14, 2019 10:42 PM
> To: Lin, Wayne
> Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
>
> On Mon, Oct 14, 2019 at 09:27:07AM
Add an DMA-buf export implementation independent of the DRM helpers.
This not only avoids the caching of DMA-buf mappings, but also
allows us to use the new dynamic locking approach.
This is also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging leftover
On 21/10/2019 19:32, Chris Wilson wrote:
Currently even though i915_vma_parked() operates on a per-gt struct, it
is called from a global pm notify. This oddity was only because the long
term plan is to decouple the vma cache from the pm notification, but
right now the oddity stands out like a so
On 21/10/2019 19:32, Chris Wilson wrote:
With the last user, i915_vma_parked(), retired, there are no more users
of the per-gt pm notifications and we can remove the unused
infrastructure.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 25 -
== Series Details ==
Series: drm/i915/gt: Introduce barrier pulses along engines (rev4)
URL : https://patchwork.freedesktop.org/series/68309/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1b7f5f7aef7e drm/i915/gt: Introduce barrier pulses along engines
-:32: WARNING:FILE_PATH_C
Simple test writing to dwords across an object, using various engines in
a randomized order, checking that our writes land from the cpu.
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
.../drm/i915/selftests/intel_memory_region.c | 166 ++
1 file changed, 166 insertio
From: Abdiel Janulgue
We can create LMEM objects, but we also need to support mapping them
into kernel space for internal use.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Signed-off-by: Steve Hampson
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/
Add LMEM objects to list of backends we test for huge-GTT-pages.
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 121 +-
1 file changed, 120 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/hu
Now that for all the relevant backends we do randomised testing, we need
to make sure we still sanity check the obvious cases that might blow up,
such that introducing a temporary regression is less likely. Also
rather than do this for every backend, just limit to our two memory
types: system and
We currently define LMEM, or local memory, as just another memory
region, like system memory or stolen, which we can expose to userspace
and can be mapped to the CPU via some BAR.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/Makefile
From: Abdiel Janulgue
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_region_lmem.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
b/drivers/gpu/dr
Ditch the dubious static list of sizes to enumerate, in favour of
choosing a random size within the limits of each backing store. With
repeated CI runs this should give us a wider range of object sizes, and
in turn more page-size combinations, while using less machine time.
Signed-off-by: Matthew
Quoting Matthew Auld (2019-10-21 20:27:43)
> @@ -244,6 +247,13 @@ static void *i915_gem_object_map(const struct
> drm_i915_gem_object *obj,
> pgprot_t pgprot;
> void *addr;
>
> + if (i915_gem_object_is_lmem(obj)) {
> + if (type != I915_MAP_WC)
> +
Quoting Chris Wilson (2019-10-21 20:37:46)
> Quoting Matthew Auld (2019-10-21 20:27:43)
> > @@ -244,6 +247,13 @@ static void *i915_gem_object_map(const struct
> > drm_i915_gem_object *obj,
> > pgprot_t pgprot;
> > void *addr;
> >
> > + if (i915_gem_object_is_lmem(obj)) {
>
The content protection tests only start if this debugfs entry exists.
Since the name is specific to intel driver these tests cannot be used with
other drivers. So we should check generic debugfs name also
v2: Check i915_* if device is i915, otherwise check the generic name.
Signed-off-by: Bhawanp
== Series Details ==
Series: drm/i915/gt: Introduce barrier pulses along engines (rev4)
URL : https://patchwork.freedesktop.org/series/68309/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7142 -> Patchwork_14906
Summary
---
== Series Details ==
Series: series starting with [1/2] drm/i915: Lift i915_vma_parked() onto the gt
URL : https://patchwork.freedesktop.org/series/68329/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7142 -> Patchwork_14907
Quoting Matthew Auld (2019-10-21 20:27:41)
> diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
> b/drivers/gpu/drm/i915/intel_region_lmem.c
> new file mode 100644
> index ..199532056e1b
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_region_lmem.c
> @@ -0,0 +1,16 @@
> +// SPDX-L
Quoting Matthew Auld (2019-10-21 20:27:47)
> Now that for all the relevant backends we do randomised testing, we need
> to make sure we still sanity check the obvious cases that might blow up,
> such that introducing a temporary regression is less likely. Also
> rather than do this for every backe
Quoting Kumar Valsan, Prathap (2019-10-21 14:52:12)
> On Sat, Oct 19, 2019 at 12:20:18AM +0100, Chris Wilson wrote:
> > Quoting Kumar Valsan, Prathap (2019-10-19 00:24:13)
> > > On Fri, Oct 18, 2019 at 11:14:39PM +0100, Chris Wilson wrote:
> > > > +static int check_l3cc_table(struct intel_engine_cs
Hi all,
After merging the drm-misc-fixes tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
In file included from include/uapi/linux/posix_types.h:5,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
f
Hi all,
This should have been reported against the vfs-fixes tree, sorry.
On Tue, 22 Oct 2019 08:07:34 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm-misc-fixes tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> In file included from inc
== Series Details ==
Series: dma_resv lockdep annotations/priming
URL : https://patchwork.freedesktop.org/series/68312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7141_full -> Patchwork_14903_full
Summary
---
**SU
== Series Details ==
Series: series starting with [1/4] dma-buf: change DMA-buf locking convention v2
URL : https://patchwork.freedesktop.org/series/68330/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d8e1ae91bced dma-buf: change DMA-buf locking convention v2
-:374: WARNING:NO
1 - 100 of 143 matches
Mail list logo
