== Series Details ==
Series: drm/modes: Prevent division by zero htotal
URL : https://patchwork.freedesktop.org/series/55610/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468 -> Patchwork_12012
Summary
---
**SUCCES
On Mon, 21 Jan 2019, Jani Nikula wrote:
> On Fri, 18 Jan 2019, Jani Nikula wrote:
>> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>>
>> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
>>
>> v2: rebase
>>
>> Acked-by: Chris Wilson
>> Acked-by: Tvrtko Ursulin
>> Reviewed
Quoting Daniele Ceraolo Spurio (2019-01-23 02:32:27)
> When reading GEN11_GT_INTR_DWx closely after enabling the interrupts
> in gen11_irq_postinstall, the returned value is garbage. This can
> cause other parts of the setup code (e.g. gen11_reset_one_iir) to
> think that there are interrupts to be
John Harrison writes:
> On 1/21/2019 14:20, Chris Wilson wrote:
>> In preparation for the next few commits, make resetting the GPU atomic.
>> Currently, we have prepared gen6+ for atomic resetting of individual
>> engines, but now there is a requirement to perform the whole device
>> level reset
Op 22-01-2019 om 22:12 schreef Manasi Navare:
> On Gen 11 platform, to enable resolutions like 5K@120 where
> the pixel clock is greater than pipe pixel rate, we need to split it across
> 2 pipes and enable it using DSC and big joiner. In order to support this
> dual pipe single port mode, we need
On 21/01/2019 22:21, Chris Wilson wrote:
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediat
== Series Details ==
Series: drm/i915: correct the pitch check for NV12 framebuffer (rev3)
URL : https://patchwork.freedesktop.org/series/53928/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468_full -> Patchwork_12011_full
Quoting Tvrtko Ursulin (2019-01-23 09:21:45)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > -static void error_record_engine_waiters(struct intel_engine_cs *engine,
> > - struct drm_i915_error_engine *ee)
> > -{
> > - struct intel_breadcrumbs *b = &engine-
On Tue, Jan 22, 2019 at 07:34:55PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 22, 2019 at 07:22:24PM +0200, Imre Deak wrote:
> > On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > To make vblank timestamps work better with the TV encoder let's
> >
== Series Details ==
Series: drm/modes: Prevent division by zero htotal
URL : https://patchwork.freedesktop.org/series/55610/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468_full -> Patchwork_12012_full
Summary
---
On Wed, Jan 23, 2019 at 03:28:59PM +0800, Tina Zhang wrote:
> This patch prevents division by zero htotal.
How did you manage to get here with htotal == 0? This needs backtraces
(or if this is just about static checkers, a mention of that).
-Daniel
>
> Signed-off-by: Tina Zhang
> Cc: Adam Jacks
Hi Dave, Daniel,
Here is the PR for drm-misc-next for this week.
Let me know if there's anything wrong.
Thanks!
Maxime
drm-misc-next-2019-01-23:
drm-misc-next for 5.1:
UAPI Changes:
- Addition of the Allwinner tiled format modifier
Cross-subsystem Changes:
Core Changes:
- dma-buf documenta
Adds test for stack initialization coverage. We have several build options
that control the level of stack variable initialization. This test lets us
visualize which options cover which cases, and provide tests for options
that are currently not available (padding initialization).
All options pass
This adds a new plugin "stackinit" that attempts to perform unconditional
initialization of all stack variables[1]. It has wider effects than
GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y since BYREF_ALL does not consider
non-structures. A notable weakness is that padding bytes in many cases
remain uninitializ
This attempts to duplicate the proposed gcc option -finit-local-vars[1]
in an effort to implement the "always initialize local variables" kernel
development goal[2].
Enabling CONFIG_GCC_PLUGIN_STACKINIT should stop all "uninitialized
stack variable" flaws as long as they don't depend on being zero
Variables declared in a switch statement before any case statements
cannot be initialized, so move all instances out of the switches.
After this, future always-initialized stack variables will work
and not throw warnings like this:
fs/fcntl.c: In function ‘send_sigio_to_task’:
fs/fcntl.c:738:13: w
== Series Details ==
Series: gcc-plugins: Introduce stackinit plugin
URL : https://patchwork.freedesktop.org/series/55630/
State : failure
== Summary ==
Applying: treewide: Lift switch variables out of switches
Using index info to reconstruct a base tree...
M drivers/gpu/drm/drm_edid.c
M
On 18/01/2019 14:00, Chris Wilson wrote:
In preparation to making the ppGTT binding for a context explicit (to
facilitate reusing the same ppGTT between different contexts), allow the
user to create and destroy named ppGTT.
Needs some more text to explain uAPI usage, or even better kerneldoc i
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled, without
Daniele Ceraolo Spurio writes:
> On 1/22/2019 6:32 PM, Daniele Ceraolo Spurio wrote:
>> When reading GEN11_GT_INTR_DWx closely after enabling the interrupts
>> in gen11_irq_postinstall, the returned value is garbage. This can
>
> To clarify, this only happens (or at least I've only seen it) durin
Quoting Tvrtko Ursulin (2019-01-23 11:30:39)
> > +int i915_gem_vm_create_ioctl(struct drm_device *dev, void *data,
> > + struct drm_file *file)
> > +{
> > + struct drm_i915_private *i915 = to_i915(dev);
> > + struct drm_i915_gem_vm_create *args = data;
> > + str
On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
== Series Details ==
Series: series starting with [01/34] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55528/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a3cfcd69db36 drm/i915/execlists: Mark up priority boost
Chris Wilson writes:
> Quoting Daniele Ceraolo Spurio (2019-01-23 02:32:27)
>> When reading GEN11_GT_INTR_DWx closely after enabling the interrupts
>> in gen11_irq_postinstall, the returned value is garbage. This can
>> cause other parts of the setup code (e.g. gen11_reset_one_iir) to
>> think th
On 18/01/2019 14:01, Chris Wilson wrote:
Allow the user to share ppGTT between contexts on the same fd. This
gives the user the ability to relax their context isolation to share vm
between their own contexts, but does not allow them to import a vm from
another fd. The use case for sharing a vm i
"Souza, Jose" writes:
> On Thu, 2019-01-17 at 21:59 -0800, Rodrigo Vivi wrote:
>> We just got aware that there was more IDs available
>> at spec, so let's add them already.
>
> Reviewed-by: José Roberto de Souza
Pushed. Thank you for patch and review.
-Mika
>
>>
>> Cc: James Ausmus
>> Cc: Jo
On 23/01/2019 11:51, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-23 11:30:39)
+int i915_gem_vm_create_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct drm_i915_gem_vm_create *a
== Series Details ==
Series: series starting with [01/34] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55528/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists: Mark up
Quoting Tvrtko Ursulin (2019-01-23 12:00:49)
>
> On 18/01/2019 14:01, Chris Wilson wrote:
> > Allow the user to share ppGTT between contexts on the same fd. This
> > gives the user the ability to relax their context isolation to share vm
> > between their own contexts, but does not allow them to i
Record the priority boost we giving to the preempted client or else we
may end up in a situation where the priority queue no longer matches the
request priority order and so we can end up in an infinite loop of
preempting the same pair of requests.
Fixes: e9eaf82d97a2 ("drm/i915: Priority boost fo
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We c
== Series Details ==
Series: series starting with [01/34] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55528/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5469 -> Patchwork_12014
==
Quoting Tvrtko Ursulin (2019-01-22 15:50:27)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > The global seqno is defunct and so we have no meaningful indicator of
> > forward progress for an engine. You need to listen to the request
> > signaling tracepoints instead.
> >
> > Signed-off-by: Chris
On 23/01/2019 12:54, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-22 15:50:27)
On 21/01/2019 22:21, Chris Wilson wrote:
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption
URL : https://patchwork.freedesktop.org/series/55638/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6817512a013e drm/i915/execlists: Mark up priority boost on preem
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption
URL : https://patchwork.freedesktop.org/series/55638/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists: Mark up priority
Quoting Tvrtko Ursulin (2019-01-23 13:18:43)
>
> On 23/01/2019 12:54, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-22 15:50:27)
> >>
> >> On 21/01/2019 22:21, Chris Wilson wrote:
> >>> The global seqno is defunct and so we have no meaningful indicator of
> >>> forward progress for an en
On 23/01/2019 12:36, Chris Wilson wrote:
Record the priority boost we giving to the preempted client or else we
may end up in a situation where the priority queue no longer matches the
request priority order and so we can end up in an infinite loop of
preempting the same pair of requests.
Fixes
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption
URL : https://patchwork.freedesktop.org/series/55638/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5470 -> Patchwork_12015
===
Quoting Chris Wilson (2019-01-23 12:36:02)
> On unwinding the active request we give it a small (limited to internal
> priority levels) boost to prevent it from being gazumped a second time.
> However, this means that it can be promoted to above the request that
> triggered the preemption request,
On Mon, Nov 12, 2018 at 06:59:59PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On gen3 we must disable the TV encoder vertical filter for >1024
> pixel wide sources. Once that's done all we can is try to center
> the image on the screen. Naturally the TV mode vertical resolution
> must
On Mon, Nov 12, 2018 at 07:00:00PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since gen3 can't handle >1024 wide sources with vertical scaling
> let's not advertize such modes in the mode list. Less tempetation
> to the user to try out things that won't work.
>
> Signed-off-by: Ville
Record the priority boost we giving to the preempted client or else we
may end up in a situation where the priority queue no longer matches the
request priority order and so we can end up in an infinite loop of
preempting the same pair of requests.
Fixes: e9eaf82d97a2 ("drm/i915: Priority boost fo
== Series Details ==
Series: drm/i915/execlists: Mark up priority boost on preemption
URL : https://patchwork.freedesktop.org/series/55641/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists: Mark up priority boost on preemption
+drivers
On 23/01/2019 12:36, Chris Wilson wrote:
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing cont
Quoting Chris Wilson (2019-01-23 13:47:29)
> Quoting Chris Wilson (2019-01-23 12:36:02)
> > On unwinding the active request we give it a small (limited to internal
> > priority levels) boost to prevent it from being gazumped a second time.
> > However, this means that it can be promoted to above th
On Wed, 23 Jan 2019, Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>> Variables declared in a switch statement before any case statements
>> cannot be initialized, so move all instances out of the switches.
>> After this, future always-initialized stack variables will
The subject of this patch could really be bit more specific "... on DDI clock
selection".
Regards, Joonas
Quoting Lucas De Marchi (2019-01-17 22:21:10)
> Even if we don't have the correct clock and get a warning, we should not
> skip the return.
>
> Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start addi
== Series Details ==
Series: drm/i915/execlists: Mark up priority boost on preemption
URL : https://patchwork.freedesktop.org/series/55641/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5470 -> Patchwork_12016
Summary
-
On Wed, 23 Jan 2019, Jani Nikula wrote:
> On Wed, 23 Jan 2019, Greg KH wrote:
>> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>>> Variables declared in a switch statement before any case statements
>>> cannot be initialized, so move all instances out of the switches.
>>> After this,
Quoting Tvrtko Ursulin (2019-01-23 14:08:56)
>
> On 23/01/2019 12:36, Chris Wilson wrote:
> > In order to avoid preempting ourselves, we currently refuse to schedule
> > the tasklet if we reschedule an inflight context. However, this glosses
> > over a few issues such as what happens after a CS co
Quoting Chris Wilson (2019-01-07 12:56:36)
> Since we trust fb->size as either calculated by calc_fb_size() or the
> supplied by the user, it invariably isn't page aligned. The mmap
> routines and ioctls only deal in pages...
>
> Not sure if fb->size should be page aligned, but that may break
> so
Quoting Joonas Lahtinen (2019-01-23 14:22:54)
> Quoting Chris Wilson (2019-01-07 12:56:36)
> > Since we trust fb->size as either calculated by calc_fb_size() or the
> > supplied by the user, it invariably isn't page aligned. The mmap
> > routines and ioctls only deal in pages...
> >
> > Not sure i
On Wed, 23 Jan 2019, Patchwork wrote:
> == Series Details ==
>
> Series: gcc-plugins: Introduce stackinit plugin
> URL : https://patchwork.freedesktop.org/series/55630/
> State : failure
>
> == Summary ==
>
> Applying: treewide: Lift switch variables out of switches
> Using index info to reconst
Quoting Chris Wilson (2019-01-23 14:14:05)
> Quoting Chris Wilson (2019-01-23 13:47:29)
> > Quoting Chris Wilson (2019-01-23 12:36:02)
> > > On unwinding the active request we give it a small (limited to internal
> > > priority levels) boost to prevent it from being gazumped a second time.
> > > Ho
Quoting Joerg Roedel (2019-01-22 18:51:35)
> On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> > According to our IOMMU folks there exists some desire to be able to assign
> > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> > due to how the devices might b
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We c
This pair, gem_exec_nop/{series,parallel}, are very light stress tests
of which we already perform the same sequence inside
i915_selftests/live_requests. We keep basic uABI coverage (i.e. plain
old gem_execbuf) via the likes of gem_exec_basic and gem_exec_reloc so
all gem_exec_nop adds are nefariou
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55638/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8de30aea3cc3 drm/i915/execlists: Mark up priority boost o
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55638/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists: Mark up pr
On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> On Wed, 23 Jan 2019, Jani Nikula wrote:
>> On Wed, 23 Jan 2019, Greg KH wrote:
>> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>> >> Variables declared in a switch statement before any case statements
>> >> cannot be initialized, so m
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55638/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5470 -> Patchwork_12017
On 23/01/2019 10:01, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-23 09:21:45)
On 21/01/2019 22:21, Chris Wilson wrote:
-static void error_record_engine_waiters(struct intel_engine_cs *engine,
- struct drm_i915_error_engine *ee)
-{
- struct intel
== Series Details ==
Series: drm/i915/execlists: Mark up priority boost on preemption
URL : https://patchwork.freedesktop.org/series/55641/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5470_full -> Patchwork_12016_full
Sum
On Wed, Jan 23, 2019 at 03:49:02PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:59:59PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On gen3 we must disable the TV encoder vertical filter for >1024
> > pixel wide sources. Once that's done all we can is try to center
> > the
On 23/01/2019 14:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-23 14:08:56)
On 23/01/2019 12:36, Chris Wilson wrote:
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such
On Wed, Jan 23, 2019 at 05:02:38PM +0200, Joonas Lahtinen wrote:
> We have many reports where just having intel_iommu=on (and using the
> system normally, without any virtualization stuff going on) will cause
> unexplained GPU hangs. For those users, simply switching to
> intel_iommu=igfx_off solve
On Wed, 2019-01-23 at 03:03 -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
>
> fs
On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be initialized, so move all instances out of the switches.
> > After this, future always-initialized stack
On Wed, 23 Jan 2019 at 13:09, Jann Horn wrote:
>
> On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > > Variables declared in a switch statement before any case statements
> > > cannot be initialized, so move all instances out of the
> On Jan 23, 2019, at 5:09 AM, Jann Horn wrote:
>
> AFAICS this only applies to switch statements (because they jump to a
> case and don't execute stuff at the start of the block), not blocks
> after if/while/... .
It bothers me that we are going out of our way to deprecate valid C constructs
On Wed, 23 Jan 2019, Jani Nikula wrote:
> On Wed, 23 Jan 2019, Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> >> Variables declared in a switch statement before any case statements
> >> cannot be initialized, so move all instances out of the switches.
> >> After t
On Tue, Jan 22, 2019 at 01:12:07PM -0800, Manasi Navare wrote:
> On Gen 11 platform, to enable resolutions like 5K@120 where
> the pixel clock is greater than pipe pixel rate, we need to split it across
> 2 pipes and enable it using DSC and big joiner. In order to support this
> dual pipe single po
Hi Daniel.
On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here
Quoting Tvrtko Ursulin (2019-01-23 16:40:44)
>
> On 23/01/2019 14:22, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-23 14:08:56)
> >>
> >> On 23/01/2019 12:36, Chris Wilson wrote:
> >>> In order to avoid preempting ourselves, we currently refuse to schedule
> >>> the tasklet if we resche
On Tue, Jan 22, 2019 at 01:12:07PM -0800, Manasi Navare wrote:
> On Gen 11 platform, to enable resolutions like 5K@120 where
> the pixel clock is greater than pipe pixel rate, we need to split it across
> 2 pipes and enable it using DSC and big joiner. In order to support this
> dual pipe single po
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We c
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption (rev3)
URL : https://patchwork.freedesktop.org/series/55638/
State : failure
== Summary ==
Applying: drm/i915/execlists: Mark up priority boost on preemption
Using index info to re
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/execlists: Suppress preempting
self
URL : https://patchwork.freedesktop.org/series/55648/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b7170f749928 drm/i915/execlists: Suppress preempting self
-:22: WARNING:C
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/execlists: Suppress preempting
self
URL : https://patchwork.freedesktop.org/series/55648/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists: Suppress preempting self
-
CC'ing people who have commits related to this series.
Could you take a look on it?
thanks
Lucas De Marchi
On Thu, Jan 17, 2019 at 12:21:08PM -0800, Lucas De Marchi wrote:
Some PLL reworks on ICL. Patches are more or less independent of each
other, but touch the same part of the code.
Lucas De
On Wed, Jan 23, 2019 at 04:19:30PM +0200, Joonas Lahtinen wrote:
The subject of this patch could really be bit more specific "... on DDI clock
selection".
Fixed. I'll wait for reviews on other patches to re-spin this series as
it's already conflicting.
thanks
Lucas De Marchi
Regards, Joonas
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/execlists: Suppress preempting
self
URL : https://patchwork.freedesktop.org/series/55648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5471 -> Patchwork_12019
== Series Details ==
Series: series starting with [1/3] drm/i915/execlists: Mark up priority boost
on preemption (rev2)
URL : https://patchwork.freedesktop.org/series/55638/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5470_full -> Patchwork_12017_full
==
On Wed, Jan 23, 2019 at 07:21:57AM +, Kahola, Mika wrote:
> On Tue, 2019-01-22 at 21:09 +0200, Ville Syrjälä wrote:
> > On Tue, Jan 22, 2019 at 08:09:40PM +0200, Jani Nikula wrote:
> > > On Tue, 22 Jan 2019, Ville Syrjälä
> > > wrote:
> > > > On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kaho
On 2019-01-22 06:12, Lucas De Marchi wrote:
Make the defines for LE and L3 caching options to contain the shifts and
remove the zeros from the tables as shifting zeros always result in
zero.
Starting from Ice Lake the MOCS table is defined in the spec and
contains all entries. So to simplify c
On 2019-01-22 06:12, Lucas De Marchi wrote:
Instead of initializing them to uncached, let's set them to PTE for
kernel tracking. While at it do some minor adjustments to comments and
coding style.
Signed-off-by: Lucas De Marchi
Reviewed-by: Tomasz Lis
One comment (with no expectations for c
On 2019-01-22 06:12, Lucas De Marchi wrote:
From: Tomasz Lis
The MOCS tables are going to be very similar across platforms.
To reduce the amount of copied code, this patch rips the common part and
puts it into a definition valid for all gen9 platforms.
v2: Made defines for or-ing flags. Ren
On Tue, Jan 22, 2019 at 10:23:05AM +0200, Jani Nikula wrote:
> Clarify that the name is specific to ILK+ PCH platforms.
>
> v2: prefix the name with ilk rather than pch (Ville)
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
>
On Tue, Jan 22, 2019 at 10:23:06AM +0200, Jani Nikula wrote:
> Gen 2 mobile and not I830 is, in fact, I85X. Simplify.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+),
On Tue, Jan 22, 2019 at 10:23:07AM +0200, Jani Nikula wrote:
> The VBT int_crt_support can't be trusted on earlier platforms, and is
> always set to true in intel_bios.c for pre-DDI and pre-VLV platforms. We
> can simplify the output setup by unconditionally calling
> intel_crt_init() for these pla
On 01/23/2019 03:40 AM, Mika Kuoppala wrote:
Daniele Ceraolo Spurio writes:
On 1/22/2019 6:32 PM, Daniele Ceraolo Spurio wrote:
When reading GEN11_GT_INTR_DWx closely after enabling the interrupts
in gen11_irq_postinstall, the returned value is garbage. This can
To clarify, this only happ
On Wed, Jan 23, 2019 at 07:33:35PM +0100, Tomasz Lis wrote:
On 2019-01-22 06:12, Lucas De Marchi wrote:
Instead of initializing them to uncached, let's set them to PTE for
kernel tracking. While at it do some minor adjustments to comments and
coding style.
Signed-off-by: Lucas De Marchi
Rev
On 2019-01-22 06:12, Lucas De Marchi wrote:
Let's use a macro to make tables smaller and at the same time allow us
to add fields that apply to all entries in future.
For the sake of readability, I'm calling an exception on 80 chars limit.
Lines are aligned for easy comparison of the entry valu
On 2019-01-22 06:12, Lucas De Marchi wrote:
Instead of considering we have defined entries for any index in the
table, let's keep track of the ones we explicitly defined. This will
allow Gen 11 to have it's new table defined in which we have holes of
undefined entries.
Repeated comments about
Some unpowered USB type-c dongles requires some time to power on
before being able to process aux channel transactions.
It was not a problem for older platforms because there was a hardware
bridge between DDI/DP ports and type-c controller adding a implicit
delay that hid this issue but ICL have t
On Tue, Jan 22, 2019 at 09:37:02PM +, Chris Wilson wrote:
Quoting Lucas De Marchi (2019-01-22 21:33:25)
On Tue, Jan 22, 2019 at 6:32 AM Chris Wilson wrote:
>
> Quoting Lucas De Marchi (2019-01-22 05:12:24)
> > Let's use a macro to make tables smaller and at the same time allow us
> > to add
1 - 100 of 142 matches
Mail list logo
