On Mon, Mar 11, 2019 at 08:59:00PM -0700, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 34e07e42c55aeaa78e93b057a6664e2ecde3fadb
> Author: Chris Wilson
> Date: Thu Feb 8 10:54:48 2018 +
>
> drm/i915: Add missing kerneldoc for 'ent' in i915_driver_init_early
>
>
> On Mar 11, 2019, at 5:15 PM, Pandiyan, Dhinakaran
> wrote:
>
>> On Mon, 2019-03-11 at 16:28 -0700, Rodrigo Vivi wrote:
>> On Tue, Mar 05, 2019 at 03:47:33PM -0800, José Roberto de Souza
>> wrote:
>>> This will make hsw_activate_psr1() more easy to read and will make
>>> future modification
On Mon, 2019-03-11 at 16:28 -0700, Rodrigo Vivi wrote:
> On Tue, Mar 05, 2019 at 03:47:33PM -0800, José Roberto de Souza
> wrote:
> > This will make hsw_activate_psr1() more easy to read and will make
> > future modification to TPS registers more easy to review and read.
> >
> > Cc: Dhinakaran
On Mon, Mar 11, 2019 at 04:38:00PM -0700, Souza, Jose wrote:
> On Mon, 2019-03-11 at 16:34 -0700, Rodrigo Vivi wrote:
> > On Tue, Mar 05, 2019 at 03:47:34PM -0800, José Roberto de Souza
> > wrote:
> > > TPS4 support was added to PSR because HBR3/PSR spec was not closed
> > > when ICL was freezed
On Mon, 2019-03-11 at 16:34 -0700, Rodrigo Vivi wrote:
> On Tue, Mar 05, 2019 at 03:47:34PM -0800, José Roberto de Souza
> wrote:
> > TPS4 support was added to PSR because HBR3/PSR spec was not closed
> > when ICL was freezed so if HBR3 was supported by PSR, ICL would
> > already be ready but it
On Tue, Mar 05, 2019 at 03:47:34PM -0800, José Roberto de Souza wrote:
> TPS4 support was added to PSR because HBR3/PSR spec was not closed
> when ICL was freezed so if HBR3 was supported by PSR, ICL would
> already be ready but it was not added to spec so lets always
> disable TPS4.
>
> v3:
On Tue, Mar 05, 2019 at 03:47:33PM -0800, José Roberto de Souza wrote:
> This will make hsw_activate_psr1() more easy to read and will make
> future modification to TPS registers more easy to review and read.
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
>
Den 11.03.2019 20.29, skrev Daniel Vetter:
> On Mon, Mar 11, 2019 at 08:23:38PM +0100, Daniel Vetter wrote:
>> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
>>> This adds support for outputting kernel messages on panic().
>>> A kernel message dumper is used to dump the log. The
Den 11.03.2019 20.23, skrev Daniel Vetter:
> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
>> This adds support for outputting kernel messages on panic().
>> A kernel message dumper is used to dump the log. The dumper iterates
>> over each DRM device and it's crtc's to find
On Tue, Mar 05, 2019 at 03:47:32PM -0800, José Roberto de Souza wrote:
> A new field with the training pattern(TP) wakeup time for PSR2 was
> added to VBT, so lets use it when available otherwise it will
> fallback to PSR1 wakeup time.
>
> v2: replacing enum to numerical usec time (Jani)
>
>
Hi Noralf.
Nice!
> +++ b/drivers/gpu/drm/drm_panic.c
> @@ -0,0 +1,363 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright 2018 Noralf Trønnes
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
>
On Mon, Mar 11, 2019 at 08:23:38PM +0100, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> > This adds support for outputting kernel messages on panic().
> > A kernel message dumper is used to dump the log. The dumper iterates
> > over each DRM device and
On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> This adds support for outputting kernel messages on panic().
> A kernel message dumper is used to dump the log. The dumper iterates
> over each DRM device and it's crtc's to find suitable framebuffers.
>
> All the other dumpers are
On Mon, Mar 11, 2019 at 11:12:06AM +0200, Jani Nikula wrote:
> On Fri, 08 Mar 2019, Lucas De Marchi wrote:
> > On Fri, Mar 08, 2019 at 02:39:36PM -0800, Rodrigo Vivi wrote:
> >>> Given that every platform so far has had different oa configurations,
> >>> that looks to be a hasty assumption that
On Mon, Mar 11, 2019 at 06:42:15PM +0100, Noralf Trønnes wrote:
> This patchset adds a way for DRM drivers to display kernel messages
> during panic().
>
> I had a Windows blue screen last year and remembered this patchset, so I
> did a new version that I never got around to put out. Now that
If the allocation fails, return false to avoid potential
NULL pointer dereference
Signed-off-by: Kangjie Lu
---
drivers/gpu/drm/i915/i915_gpu_error.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
On Mon, Mar 11, 2019 at 01:52:13PM -0400, Adam Jackson wrote:
> On Mon, 2019-03-11 at 12:19 +0100, Maarten Lankhorst wrote:
> > Hey,
> >
> > Op 07-03-2019 om 18:12 schreef Adam Jackson:
> > > On Thu, 2019-03-07 at 10:48 +0100, Maarten Lankhorst wrote:
> > > > Hi Sean and Joonas,
> > > >
> > > >
On Mon, 2019-03-11 at 12:19 +0100, Maarten Lankhorst wrote:
> Hey,
>
> Op 07-03-2019 om 18:12 schreef Adam Jackson:
> > On Thu, 2019-03-07 at 10:48 +0100, Maarten Lankhorst wrote:
> > > Hi Sean and Joonas,
> > >
> > > Here's a pull request for HDR format enabling in i915. Can this be pulled
> >
Add drm_fb_cma_fb_create() which creates a framebuffer that supports
panic message output.
vmap PRIME buffers on import to support panic on those as well. There
is no atomic way to get a virtual address on a dma_buf.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_cma_helper.c | 43
Use drm_fb_cma_fb_create() to get panic screen support.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/vc4/vc4_kms.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index
This adds support for outputting kernel messages on panic().
A kernel message dumper is used to dump the log. The dumper iterates
over each DRM device and it's crtc's to find suitable framebuffers.
All the other dumpers are run before this one except mtdoops.
Only atomic drivers are supported.
This patchset adds a way for DRM drivers to display kernel messages
during panic().
I had a Windows blue screen last year and remembered this patchset, so I
did a new version that I never got around to put out. Now that panic
handling came up on the ML, I'm sending it out as part of the
Quoting Tvrtko Ursulin (2019-03-11 16:34:41)
>
> On 11/03/2019 16:22, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-11 16:16:27)
> >>
> >> On 11/03/2019 14:45, Chris Wilson wrote:
> >>> Quoting Chris Wilson (2019-03-11 09:45:17)
> Quoting Tvrtko Ursulin (2019-03-11 09:23:44)
>
On 11/03/2019 16:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-11 16:16:27)
On 11/03/2019 14:45, Chris Wilson wrote:
Quoting Chris Wilson (2019-03-11 09:45:17)
Quoting Tvrtko Ursulin (2019-03-11 09:23:44)
On 08/03/2019 16:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin
On Fri, Mar 08, 2019 at 07:57:22PM -0800, Lucas De Marchi wrote:
> v2 of https://patchwork.freedesktop.org/series/57618/
>
> Only difference is that patch 2 got replaced with a different one.
> Instead of passing a function pointer to write the pll, split the
> function in three and pass the
Quoting Tvrtko Ursulin (2019-03-11 16:16:27)
>
> On 11/03/2019 14:45, Chris Wilson wrote:
> > Quoting Chris Wilson (2019-03-11 09:45:17)
> >> Quoting Tvrtko Ursulin (2019-03-11 09:23:44)
> >>>
> >>> On 08/03/2019 16:47, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-03-08 16:27:22)
>
On 11/03/2019 14:45, Chris Wilson wrote:
Quoting Chris Wilson (2019-03-11 09:45:17)
Quoting Tvrtko Ursulin (2019-03-11 09:23:44)
On 08/03/2019 16:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-08 16:27:22)
On 08/03/2019 14:12, Chris Wilson wrote:
+static int
+set_engines(struct
Chris Wilson writes:
> It should be (count, size)!
/o\
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> tests/i915/gem_ppgtt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c
> index
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Monday, March 11, 2019 7:42 PM
>To: Shankar, Uma ; Patchwork
>
>Cc: intel-gfx@lists.freedesktop.org
>Subject: RE: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add HDR Metadata
>Parsing
>and handling in DRM
Quoting Chris Wilson (2019-03-11 09:45:17)
> Quoting Tvrtko Ursulin (2019-03-11 09:23:44)
> >
> > On 08/03/2019 16:47, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2019-03-08 16:27:22)
> > >>
> > >> On 08/03/2019 14:12, Chris Wilson wrote:
> > >>> +static int
> > >>> +set_engines(struct
Quoting Tvrtko Ursulin (2019-03-11 13:38:52)
>
> On 08/03/2019 14:12, Chris Wilson wrote:
> > @@ -3191,12 +3198,30 @@ static void virtual_submission_tasklet(unsigned
> > long data)
> > return;
> >
> > local_irq_disable();
> > +
> > + mask = 0;
> > +
Quoting Tvrtko Ursulin (2019-03-11 13:09:11)
>
>
> On 08/03/2019 14:12, Chris Wilson wrote:
> > +int
> > +i915_request_await_execution(struct i915_request *rq,
> > + struct dma_fence *fence,
> > + void (*hook)(struct i915_request *rq,
> > +
It should be (count, size)!
Signed-off-by: Chris Wilson
---
tests/i915/gem_ppgtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/gem_ppgtt.c b/tests/i915/gem_ppgtt.c
index 9409bef14..ae9869c2c 100644
--- a/tests/i915/gem_ppgtt.c
+++ b/tests/i915/gem_ppgtt.c
@@
On Mon, 11 Mar 2019, "Shankar, Uma" wrote:
>>-Original Message-
>>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>>Sent: Monday, March 11, 2019 7:25 PM
>>To: Patchwork ; Shankar, Uma
>>
>>Cc: intel-gfx@lists.freedesktop.org
>>Subject: Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning
On Sat, Mar 09, 2019 at 09:34:49AM +0530, Ramalingam C wrote:
> Binary Sysfs entry is created to pass the HDCP SRM table into
> kerel for the HDCP authentication purpose.
>
> Signed-off-by: Ramalingam C
I think the srm stuff would sit very well in the drm core:
- sysfs file created in the
>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Monday, March 11, 2019 7:25 PM
>To: Patchwork ; Shankar, Uma
>
>Cc: intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add HDR Metadata
>Parsing
>and handling in DRM
On Mon, 11 Mar 2019, Patchwork wrote:
> == Series Details ==
>
> Series: Add HDR Metadata Parsing and handling in DRM layer (rev5)
> URL : https://patchwork.freedesktop.org/series/25091/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> b2d03105049d drm: Add HDR source
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Zhenyu Wang
> Sent: Monday, March 11, 2019 10:38 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915: always pin
Quoting Tvrtko Ursulin (2019-03-11 12:47:30)
>
> On 08/03/2019 14:12, Chris Wilson wrote:
> > Having allowed the user to define a set of engines that they will want
> > to only use, we go one step further and allow them to bind those engines
> > into a single virtual instance. Submitting a batch
On 08/03/2019 14:12, Chris Wilson wrote:
There is a desire to split a task onto two engines and have them run at
the same time, e.g. scanline interleaving to spread the workload evenly.
Through the use of the out-fence from the first execbuf, we can
coordinate secondary execbuf to only become
On 08/03/2019 14:12, Chris Wilson wrote:
Some users require that when a master batch is executed on one particular
engine, a companion batch is run simultaneously on a specific slave
engine. For this purpose, we introduce virtual engine bonding, allowing
maps of master:slaves to be constructed
On 08/03/2019 14:12, Chris Wilson wrote:
In the next patch, we will want to configure the slave request
depending on which physical engine the master request is executed on.
For this, we introduce a callback from the execute fence to convey this
information.
Signed-off-by: Chris Wilson
---
On 08/03/2019 14:12, Chris Wilson wrote:
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of
On Fri, Mar 01, 2019 at 10:25:02AM +0100, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/i915/i915_drv.c | 38 ++
> 1 file changed, 2 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
== Series Details ==
Series: drm/i915: Consolidate reset-request debug message
URL : https://patchwork.freedesktop.org/series/57826/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5731_full -> Patchwork_12436_full
Summary
Op 11-03-2019 om 12:57 schreef Joonas Lahtinen:
> Quoting Maarten Lankhorst (2019-03-07 11:48:24)
>> Hi Sean and Joonas,
>>
>> Here's a pull request for HDR format enabling in i915. Can this be pulled to
>> drm-misc-next and dinq?
> I was travelling on Fri, so sorry for delay. This is now pulled
Quoting Maarten Lankhorst (2019-03-07 11:48:24)
> Hi Sean and Joonas,
>
> Here's a pull request for HDR format enabling in i915. Can this be pulled to
> drm-misc-next and dinq?
I was travelling on Fri, so sorry for delay. This is now pulled to dinq,
too.
Regards, Joonas
>
> Cheers,
> Maarten
Quoting Carlos Santa (2019-02-21 02:58:14)
> This is a rebased on the original patch series from Michel Thierry
> that can be found here:
>
> https://patchwork.freedesktop.org/series/21868
>
> Note that this series is only limited to the GPU Watchdog timeout
> for execlists as it leaves out
Hey,
Op 07-03-2019 om 18:12 schreef Adam Jackson:
> On Thu, 2019-03-07 at 10:48 +0100, Maarten Lankhorst wrote:
>> Hi Sean and Joonas,
>>
>> Here's a pull request for HDR format enabling in i915. Can this be pulled to
>> drm-misc-next and dinq?
> Could you also add Kevin Strasser's patch for
== Series Details ==
Series: drm/i915: Consolidate reset-request debug message
URL : https://patchwork.freedesktop.org/series/57826/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5731 -> Patchwork_12436
Summary
---
Quoting Andi Shyti (2019-03-11 10:30:23)
> Hi again,
>
> I was thinking...
>
> > +static void bonded(int i915, unsigned int flags)
> > +#define CORK 0x1
> > +{
> > + struct class_instance *master_engines;
>
> ... shall we just make 'struct class_instance' generic in the
> uapi? I do not
On 08/03/2019 03:16, Carlos Santa wrote:
On Fri, 2019-03-01 at 09:36 +, Chris Wilson wrote:
Quoting Carlos Santa (2019-02-21 02:58:16)
+#define GEN8_WATCHDOG_1000US(dev_priv)
watchdog_to_clock_counts(dev_priv, 1000)
+static void gen8_watchdog_irq_handler(unsigned long data)
+{
+
Hi Chris,
On Fri, Mar 08, 2019 at 06:11:27PM +, Chris Wilson wrote:
> To exercise the new I915_CONTEXT_PARAM_ENGINES and interactions with
> gem_execbuf().
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Andi Shyti
> ---
I received three times this patch, could you please add
Quoting Tvrtko Ursulin (2019-03-11 07:14:48)
>
> On 08/03/2019 16:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-08 16:31:51)
> >>
> >> On 08/03/2019 14:12, Chris Wilson wrote:
> >>> Allow the user to specify a local engine index (as opposed to
> >>> class:index) that they can use to
Quoting Tvrtko Ursulin (2019-03-11 07:16:48)
>
> On 08/03/2019 17:11, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-08 16:31:51)
> >> Looks okay. But one more thing is needed:
> >>
> >>
Hi again,
I was thinking...
> +static void bonded(int i915, unsigned int flags)
> +#define CORK 0x1
> +{
> + struct class_instance *master_engines;
... shall we just make 'struct class_instance' generic in the
uapi? I do not expect every test that uses class and instance to
define its own
== Series Details ==
Series: drm/i915: Consolidate reset-request debug message
URL : https://patchwork.freedesktop.org/series/57826/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5731 -> Patchwork_12436
Summary
---
Hi Chris,
just a nitpick, a warning that came out when I applied the
patches.
> struct i915_context_engines_load_balance balancer = {
> - { .name = I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE },
> + {
^
trailing whitespace
> +
On 11/03/2019 09:45, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-11 09:23:44)
On 08/03/2019 16:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-08 16:27:22)
On 08/03/2019 14:12, Chris Wilson wrote:
+static int
+set_engines(struct i915_gem_context *ctx,
+ const
Quoting Mika Kuoppala (2019-03-11 10:04:05)
> Chris Wilson writes:
> > + mem_per_child = SIZE;
> > + if (flags & CREATE_CONTEXT)
> > + mem_per_child += 2 * 128 * 1024; /* rough context sizes */
>
> Someday libify this so that we give num context and size per each?
> Just that
Chris Wilson writes:
> fi-kbl-guc's swap ran dry while running blt-vs-render-ctxN, which is
> midly concerning but conceivable as we never checked there was enough
> memory to run the test to begin with.
>
> Each child needs to keep its own surface and possible a pair of logical
> contexts (one
Quoting Tvrtko Ursulin (2019-03-11 09:23:44)
>
> On 08/03/2019 16:47, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-03-08 16:27:22)
> >>
> >> On 08/03/2019 14:12, Chris Wilson wrote:
> >>> +static int
> >>> +set_engines(struct i915_gem_context *ctx,
> >>> + const struct
On 08/03/2019 16:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-08 16:27:22)
On 08/03/2019 14:12, Chris Wilson wrote:
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous
Move the pair of messages to the common callsite where it makes sense to
include a bit more information about which request is being reset.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 6 ++
drivers/gpu/drm/i915/intel_lrc.c| 1 -
On Fri, 08 Mar 2019, Lucas De Marchi wrote:
> On Fri, Mar 08, 2019 at 02:39:36PM -0800, Rodrigo Vivi wrote:
>>> Given that every platform so far has had different oa configurations,
>>> that looks to be a hasty assumption that future platforms will be fixed.
>>
>>I know... But my hope is that at
On 08/03/2019 17:11, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-08 16:31:51)
Looks okay. But one more thing is needed:
https://cgit.freedesktop.org/~tursulin/drm-intel/commit/?h=media=38266bfe99469de9e13774a13fa641c377988c67
drm/i915: Allow SSEU configuration to be set on virtual
On 08/03/2019 16:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-08 16:31:51)
On 08/03/2019 14:12, Chris Wilson wrote:
Allow the user to specify a local engine index (as opposed to
class:index) that they can use to refer to a preset engine inside the
ctx->engine[] array defined by an
67 matches
Mail list logo
