On Fri, 03 Apr 2020, abhin...@codeaurora.org wrote:
> On 2020-04-03 13:39, Ville Syrjala wrote:
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index fec1c33b3045..e3d5f011f7bd 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -759,9
An important ingredient to using igt_subtest_with_dynamic is to include
an igt_dynamic at some point.
Reported-by: Petri Latvala
Fixes: 311cb1b360b7 ("i915/perf_pmu: Dynamic active engine tests")
Signed-off-by: Chris Wilson
Cc: Petri Latvala
---
tests/perf_pmu.c | 3 ++-
1 file changed, 2 inse
On Mon, Apr 06, 2020 at 09:53:09AM +0100, Chris Wilson wrote:
> An important ingredient to using igt_subtest_with_dynamic is to include
> an igt_dynamic at some point.
>
> Reported-by: Petri Latvala
> Fixes: 311cb1b360b7 ("i915/perf_pmu: Dynamic active engine tests")
> Signed-off-by: Chris Wilson
On Fri, 03 Apr 2020, abhin...@codeaurora.org wrote:
> Hi Ville
>
> Thanks for the patch.
>
> Our understanding of private_flags was that we can use it within our
> drivers to handle vendor specific features.
> Hence we do have several features in our downstream drivers as well as
> some planned w
Later use will require asynchronous waits on the active timelines, but
will not utilize an async wait on the exclusive channel. Make the await
on the exclusive fence explicit in the selection flags.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 7 ---
drivers/gpu/drm/i
Allocate a few dma fence context id that we can use to associate async work
[for the CPU] launched on behalf of this context. For extra fun, we allow
a configurable concurrency width.
A current example would be that we spawn an unbound worker for every
userptr get_pages. In the future, we wish to
Sometimes we have to be very careful not to allocate underneath a mutex
(or spinlock) and yet still want to track activity. Enter
i915_active_acquire_for_context(). This raises the activity counter on
i915_active prior to use and ensures that the fence-tree contains a slot
for the context.
Signed-
Allow the caller to also wait upon the barriers stored in i915_active.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 60 ++
drivers/gpu/drm/i915/i915_active.h | 1 +
2 files changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_acti
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin. So
wait until the
If we take the user-forcewake and then exit, we find outselves in a
deadlock as the atexit handlers wait for our own forcewake to be
released. We could either not use the automatically attached exit
handler (__drm_open_driver), more carefully unwind the exit handler, or
simply avoid doing late requ
Similar to gem_tiled_blits and gem_linear_blits, we only need to just
force the system to be thrashing the GTT for the test to be effective,
so trim the working set to just a be one element larger than could fit,
and parallelise the checking across multiple cpus.
Closes: https://gitlab.freedesktop
== Series Details ==
Series: series starting with [1/5] drm/i915: Make exclusive awaits on
i915_active optional
URL : https://patchwork.freedesktop.org/series/75535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8259 -> Patchwork_17215
All the information for hangcheck is pulled into i915_engine_info so the
separate dump is redundant.
Signed-off-by: Chris Wilson
Cc: Andi Shyti
---
tests/i915/gem_busy.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/i915/gem_busy.c b/tests/i915/gem_busy.c
index 64e6fe6bd..5e4e2d939 1
On Thu, Apr 02, 2020 at 02:48:04PM +0300, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga , with
On Mon, 06 Apr 2020, "Bharadiya,Pankaj"
wrote:
> On Thu, Apr 02, 2020 at 02:48:04PM +0300, Jani Nikula wrote:
>> Convert all the DRM_* logging macros to the struct drm_device based
>> macros to provide device specific logging.
>>
>> No functional changes.
>>
>> Generated using the following sem
On Thu, Apr 02, 2020 at 02:48:06PM +0300, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga , with
On Mon, Apr 06, 2020 at 02:07:44PM +0300, Jani Nikula wrote:
> On Mon, 06 Apr 2020, "Bharadiya,Pankaj"
> wrote:
> > On Thu, Apr 02, 2020 at 02:48:04PM +0300, Jani Nikula wrote:
> >> Convert all the DRM_* logging macros to the struct drm_device based
> >> macros to provide device specific logging.
Hi Chris,
On Mon, Apr 06, 2020 at 12:00:26PM +0100, Chris Wilson wrote:
> All the information for hangcheck is pulled into i915_engine_info so the
> separate dump is redundant.
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
Reviewed-by: Andi Shyti
now we can get rid of i915_hangcheck_info.
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
Now we have struct drm_device specific drm_WARN* macros which include
device information in the backtrace, so we know what device the
warnings originate from.
This series converts WARN* with drm_WARN* where struct drm_device
pointer can be extracted.
This series is the continuation of:
https://pa
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 4 ++--
1 file changed, 2 inserti
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* calls.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_ddi.c | 14 --
1 file changed, 8 ins
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* at places where struct intel_dp struct
pointer is available.
Conversion is done with below sementic patch:
@@
identifier func,
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_frontbuffer.c | 6 --
1 file changed, 4 insert
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON at places where struct drm_device
pointer can be extracted.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/displ
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* calls.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_global_state.c | 4 ++--
1 file changed, 2 inser
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Conversion is done with below sementic patch:
@@
identifier func, T;
@@
func(struct intel_digital_port *T,...) {
<+...
-WA
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_overlay.c | 6 +++---
1 file changed, 3 insertions
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* calls.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 16 +---
1 file changed, 9
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON at places where struct i915_power_domains
struct is available.
Conversion is done with below sementic patch:
@@
identifier
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON at places where struct drm_device
pointer can be extracted.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/displ
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN*.
Conversion is done with below semantic patch:
@@
identifier func, T;
@@
func(struct intel_runtime_pm *T,...) {
+ struct drm_i9
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* at places where struct drm_device pointer
can be extracted.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/gem/i915_
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Conversion is done with below sementic patch:
@@
identifier func, T;
@@
func(...) {
...
struct intel_crtc *T = ...;
<+...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_pmu.c | 11 ---
1 file changed, 8 insertions(+), 3
On 06/04/2020 10:12, Chris Wilson wrote:
Later use will require asynchronous waits on the active timelines, but
will not utilize an async wait on the exclusive channel. Make the await
on the exclusive fence explicit in the selection flags.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i91
__i915_gem_object_flush_map() takes a byte range, so feed it the written
bytes and do not mistake the u32 index as bytes!
Fixes: a679f58d0510 ("drm/i915: Flush pages on acquisition")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: # v5.2+
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8
Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> We're mostly there already, just a handful of places that didn't use
> the to_udl container_of cast. To make sure no new appear, don't set
> ->dev_private.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Sean Paul
> Cc: Emil Velikov
> Cc
== Series Details ==
Series: Prefer drm_WARN* over WARN*
URL : https://patchwork.freedesktop.org/series/75543/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2b3269120530 drm/i915/display/icl_dsi: Prefer drm_WARN_ON over WARN_ON
ce36d1d4c808 drm/i915/display/atomic_plane: Prefer
Hi Daniel,
Thank you for the patch.
On Fri, Apr 03, 2020 at 03:57:46PM +0200, Daniel Vetter wrote:
> The kerneldoc is only added for this new function. Existing kerneldoc
> and examples will be udated at the very end, since once all drivers
> are converted over to devm_drm_dev_alloc we can unexpo
On 06/04/2020 10:12, Chris Wilson wrote:
Allow the caller to also wait upon the barriers stored in i915_active.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 60 ++
drivers/gpu/drm/i915/i915_active.h | 1 +
2 files changed, 61 insertions
On 06/04/2020 10:12, Chris Wilson wrote:
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse
On Mon, Apr 6, 2020 at 2:01 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Fri, Apr 03, 2020 at 03:57:46PM +0200, Daniel Vetter wrote:
> > The kerneldoc is only added for this new function. Existing kerneldoc
> > and examples will be udated at the very end, since onc
== Series Details ==
Series: Prefer drm_WARN* over WARN*
URL : https://patchwork.freedesktop.org/series/75543/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8259 -> Patchwork_17216
Summary
---
**FAILURE**
Serious
On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote:
>
> In drm we've added nice drm_device (the main gpu driver thing, which
> also represents the userspace interfaces and has everything else
> dangling off it) init functions using devres, devm_drm_dev_init and
> soon devm_drm_dev_alloc (this patc
If we set the debug flag to force ourselves not to relocate via the gpu,
do not relocate via the gpu.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_
On Mon, 06 Apr 2020, "Bharadiya,Pankaj"
wrote:
> Adding new i915 variable seems to be redundant here since we can
> directly use "connector->base.dev" for getting struct drm_device
> pointer.
We could. However, struct drm_i915_private *i915 is widely used and
needed throughout the driver, all o
On Mon, 06 Apr 2020, "Bharadiya,Pankaj"
wrote:
> On Thu, Apr 02, 2020 at 02:48:06PM +0300, Jani Nikula wrote:
>> Convert all the DRM_* logging macros to the struct drm_device based
>> macros to provide device specific logging.
>>
>> No functional changes.
>>
>> Generated using the following sem
== Series Details ==
Series: drm/i915/gem: Flush all the reloc_gpu batch
URL : https://patchwork.freedesktop.org/series/75544/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8259 -> Patchwork_17217
Summary
---
**FAILU
On Fri, Apr 03, 2020 at 04:18:54AM +0300, Souza, Jose wrote:
> Hi Imre
>
> I guess I did all the requested changes but trybot got some
> warnings that I will need more time to understand and fix it.
>
> If you have time please check if is this way that you are asking:
> https://github.com/zehorti
Quoting Tvrtko Ursulin (2020-04-06 13:06:03)
>
> On 06/04/2020 10:12, Chris Wilson wrote:
> > Allow the caller to also wait upon the barriers stored in i915_active.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_active.c | 60 ++
> > driv
Quoting Chris Wilson (2020-04-06 14:09:44)
> Quoting Tvrtko Ursulin (2020-04-06 13:06:03)
> >
> > On 06/04/2020 10:12, Chris Wilson wrote:
> > > Allow the caller to also wait upon the barriers stored in i915_active.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/i
== Series Details ==
Series: drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpu
URL : https://patchwork.freedesktop.org/series/75546/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8259 -> Patchwork_17218
===
Allow the caller to also wait upon the barriers stored in i915_active.
v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well
for completeness, and avoid the lazy GEM_BUG_ON()!
v3: Pull flush_lazy_signals() under the active-ref protection as it too
walks the rbtree and so we mus
== Series Details ==
Series: series starting with [1/5] drm/i915: Make exclusive awaits on
i915_active optional
URL : https://patchwork.freedesktop.org/series/75535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8259_full -> Patchwork_17215_full
==
On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote:
> >
> > In drm we've added nice drm_device (the main gpu driver thing, which
> > also represents the userspace interfaces and has everything else
> > dangling off it) init functions
On 31/03/2020 21:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
Hmm. The other thought is ctx->engine[] where one context may have more
than o
Make all the internal necessary changes before we flip the switch.
v2: Use an unlimited number of intel contexts (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 587 +++--
drivers/gpu/drm/i915/i915_perf_types.h | 23 +-
2 files changed,
We want to enable performance monitoring on multiple contexts to cover
the Iris use case of using 2 GEM contexts (3D & compute).
So start by breaking the OA configuration BO which contains global &
per context register writes.
NOA muxes & OA configurations are global, while FLEXEU register
config
On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote:
> > >
> > > In drm we've added nice drm_device (the main gpu driver thing, which
> > > also represents the userspace
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers using multiple GEM contexts to implement a
single GL context.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 58 ++
Quoting Lionel Landwerlin (2020-04-06 14:54:38)
> On 31/03/2020 21:08, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-03-31 12:48:21)
> >> Add 2 new properties to the i915-perf open ioctl to specify an array
> >> of GEM context handles as well as the length of the array.
> > Hmm. The other
On 06/04/2020 16:59, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 14:54:38)
On 31/03/2020 21:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of
== Series Details ==
Series: series starting with [1/5] drm/i915: Make exclusive awaits on
i915_active optional (rev2)
URL : https://patchwork.freedesktop.org/series/75535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8260 -> Patchwork_17219
=
== Series Details ==
Series: series starting with [1/3] drm/i915/perf: break OA config buffer object
in 2
URL : https://patchwork.freedesktop.org/series/75550/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d78a933fe510 drm/i915/perf: break OA config buffer object in 2
-:27: CH
Quoting Lionel Landwerlin (2020-04-06 15:07:30)
> On 06/04/2020 16:59, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-04-06 14:54:38)
> >> On 31/03/2020 21:08, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2020-03-31 12:48:21)
> Add 2 new properties to the i915-perf open ioctl
On 06/04/2020 17:27, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 15:07:30)
On 06/04/2020 16:59, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 14:54:38)
On 31/03/2020 21:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
Add 2 new properties to t
== Series Details ==
Series: series starting with [1/3] drm/i915/perf: break OA config buffer object
in 2
URL : https://patchwork.freedesktop.org/series/75550/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Fun
Quoting Lionel Landwerlin (2020-04-06 15:30:38)
> On 06/04/2020 17:27, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-04-06 15:07:30)
> >> On 06/04/2020 16:59, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2020-04-06 14:54:38)
> On 31/03/2020 21:08, Chris Wilson wrote:
> >
On Mon, 6 Apr 2020 at 12:48, Chris Wilson wrote:
>
> __i915_gem_object_flush_map() takes a byte range, so feed it the written
> bytes and do not mistake the u32 index as bytes!
>
> Fixes: a679f58d0510 ("drm/i915: Flush pages on acquisition")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc:
== Series Details ==
Series: series starting with [1/3] drm/i915/perf: break OA config buffer object
in 2
URL : https://patchwork.freedesktop.org/series/75550/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8260 -> Patchwork_17220
==
On Mon, 6 Apr 2020 at 13:36, Chris Wilson wrote:
>
> If we set the debug flag to force ourselves not to relocate via the gpu,
> do not relocate via the gpu.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@
== Series Details ==
Series: Prefer drm_WARN* over WARN* (rev2)
URL : https://patchwork.freedesktop.org/series/75543/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fd886b340869 drm/i915/display/icl_dsi: Prefer drm_WARN_ON over WARN_ON
5a021e68d20b drm/i915/display/atomic_plane:
On Mon, Mar 30, 2020 at 10:13:02PM +0300, Souza, Jose wrote:
> On Mon, 2020-03-30 at 12:54 +0300, Imre Deak wrote:
> > On TypeC ports if a sink deasserts/reasserts its HPD signal,
> > generating
> > a hotplug interrupt without the sink getting unplugged/replugged from
> > the connector, there can b
On Mon, Mar 16, 2020 at 04:07:59PM +0530, Animesh Manna wrote:
> This patch process phy compliance request by programming requested
> vswing, pre-emphasis and test pattern.
>
> v1: Initial patch.
> v2: Fixes added during testing with test-scope. (Khaled/Clint/Manasi)
> - pipe used as argument duri
== Series Details ==
Series: Prefer drm_WARN* over WARN* (rev2)
URL : https://patchwork.freedesktop.org/series/75543/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8260 -> Patchwork_17221
Summary
---
**SUCCESS**
N
The problem of data transfer costs is not new in Cloud environments. At
work we usually just opt for paying for it since dev time is scarser. For
private projects though, I opt for aggressive (remote) caching.
So you can setup a global cache in Google Cloud Storage and more local
caches wherever yo
Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> >
> > Thanks for the suggestion! I
On Fri, Apr 03, 2020 at 03:35:15PM -0700, Sultan Alsawaf wrote:
> + ref->retire(ref);
> + mutex_unlock(&ref->callback_lock);
Ugh, this patch is still wrong because the mutex unlock after ref->retire() is a
use-after-free. Fun times...
Sultan
___
Em Sun, Apr 05, 2020 at 05:54:37PM +0300, Alexey Budankov escreveu:
>
> On 05.04.2020 17:41, Alexey Budankov wrote:
> >
> > On 05.04.2020 17:10, Arnaldo Carvalho de Melo wrote:
> >> Em Thu, Apr 02, 2020 at 11:54:39AM +0300, Alexey Budankov escreveu:
> >>>
> >>> Update kernel.rst documentation fil
On Sat, Apr 04, 2020 at 08:11:23AM -0700, Rob Clark wrote:
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> >
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> >
> > Thanks for the suggestion
Em Thu, Apr 02, 2020 at 11:54:39AM +0300, Alexey Budankov escreveu:
>
> Update kernel.rst documentation file with the information
> related to usage of CAP_PERFMON capability to secure performance
> monitoring and observability operations in system.
This one is failing in my perf/core branch, ple
Le 03/04/2020 à 20:01, Linus Torvalds a écrit :
On Fri, Apr 3, 2020 at 12:21 AM Christophe Leroy
wrote:
Now we have user_read_access_begin() and user_write_access_begin()
in addition to user_access_begin().
I realize Al asked for this, but I don't think it really adds anything
to the serie
Hi Daniel, Dave,
Here's this week round of drm-misc-next fixes.
Thanks!
Maxime
drm-misc-next-fixes-2020-04-04:
A bunch of fixes to avoid null pointer dereference in fbcon, fix a return
in xen, some DT bindings fixes, a vc4 issue with 1920x1200 mode validation,
and a conflicting framebuffer in vb
On Sat, Apr 04, 2020 at 11:16:08AM -0700, Rob Clark wrote:
> On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote:
> >
> > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> >
Hello!
On 04.04.2020 12:40, Christoph Hellwig wrote:
Use the proper API instead.
Fixes: f440c8a572d7 ("drm/i915/gvt/kvmgt: read/write GPA via KVM API")
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Le samedi 04 avril 2020 à 15:55 +0200, Andreas Bergmeier a écrit :
> The problem of data transfer costs is not new in Cloud environments. At work
> we usually just opt for paying for it since dev time is scarser. For private
> projects though, I opt for aggressive (remote) caching.
> So you can s
The test is looking at sysfs/error so dumping the old
debugfs/i915_error_state looks quite silly. The only dilemma is whether
it is worth replacing with a line-by-line dump. I propose we make that a
future problem -- and leave it to whoever has to debug it next time.
Signed-off-by: Chris Wilson
-
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> >
> > Thanks for the suggestion! I implem
On 06/04/2020 14:21, Chris Wilson wrote:
Allow the caller to also wait upon the barriers stored in i915_active.
v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well
for completeness, and avoid the lazy GEM_BUG_ON()!
v3: Pull flush_lazy_signals() under the active-ref protec
Later use will require asynchronous waits on the active timelines, but
will not utilize an async wait on the exclusive channel. Make the await
on the exclusive fence explicit in the selection flags.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c |
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin. So
wait until the
Allow the caller to also wait upon the barriers stored in i915_active.
v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well
for completeness, and avoid the lazy GEM_BUG_ON()!
v3: Pull flush_lazy_signals() under the active-ref protection as it too
walks the rbtree and so we mus
Am 2020-04-04 um 5:40 a.m. schrieb Christoph Hellwig:
> Use the proper API instead.
>
> Fixes: 70539bd795002 ("drm/amd: Update MEC HQD loading code for KFD")
> Signed-off-by: Christoph Hellwig
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
> 1 file chan
Am 2020-04-04 um 5:40 a.m. schrieb Christoph Hellwig:
> These helpers are only for use with kernel threads, and I will tie them
> more into the kthread infrastructure going forward. Also move the
> prototypes to kthread.h - mmu_context.h was a little weird to start with
> as it otherwise contains
Hi Chris,
On Mon, Apr 06, 2020 at 04:35:18PM +0100, Chris Wilson wrote:
> The test is looking at sysfs/error so dumping the old
> debugfs/i915_error_state looks quite silly. The only dilemma is whether
> it is worth replacing with a line-by-line dump. I propose we make that a
> future problem -- a
Am 2020-04-04 um 5:41 a.m. schrieb Christoph Hellwig:
> Switch the function documentation to kerneldoc comments, and add
> WARN_ON_ONCE asserts that the calling thread is a kernel thread and
> does not have ->mm set (or has ->mm set in the case of unuse_mm).
>
> Also give the functions a kthread_ p
Upgrade the subtest to use MMAP_GTT API v4 (aka MMAP_OFFSET),
dynamically examine each mapping type supported by i915 driver.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Zbigniew Kempczyński
---
tests/i915/gem_userptr_blits.c | 21 -
1 file changed, 16 insertions(+), 5 de
1 - 100 of 153 matches
Mail list logo
