On 15/07/2019 14:30, Koenig, Christian wrote:
Hi Lionel,
sorry for the delayed response, I'm just back from vacation.
Am 03.07.19 um 11:17 schrieb Lionel Landwerlin:
On 03/07/2019 11:56, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-07-01 12:34:33)
+ syncobj = drm_syncobj
On Fri, Jul 12, 2019 at 09:03:14AM +0100, Chris Wilson wrote:
> As the set of shared fences is not being changed during reallocation of
> the reservation list, we can skip updating the write_seqlock.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Christian König
sounds legit.
Revie
On 2019.07.09 10:12:33 +0100, Chris Wilson wrote:
> Preempt-to-busy uses a GPU semaphore to enforce an idle-barrier across
> preemption, but mediated gvt does not fully support semaphores.
>
> v2: Fiddle around with the flags and settle on using has-semaphores for
> the core bits so that we retain
>-Original Message-
>From: Kulkarni, Vandita
>Sent: Tuesday, July 2, 2019 9:49 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: ville.syrj...@linux.intel.com; Nikula, Jani ;
>Shankar, Uma
>; Kulkarni, Vandita
>Subject: [PATCH 1/4] drm/i915/tgl/dsi: Program TRANS_VBLANK register
>
>Program v
>-Original Message-
>From: Kulkarni, Vandita
>Sent: Tuesday, July 2, 2019 9:49 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: ville.syrj...@linux.intel.com; Nikula, Jani ;
>Shankar, Uma
>; Kulkarni, Vandita
>Subject: [PATCH 2/4] drm/i915/tgl/dsi: Set latency PCS_DW1 for tgl
>
>Rest of the
>-Original Message-
>From: Kulkarni, Vandita
>Sent: Tuesday, July 2, 2019 9:49 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: ville.syrj...@linux.intel.com; Nikula, Jani ;
>Shankar, Uma
>; Kulkarni, Vandita
>Subject: [PATCH 3/4] drm/i915/tgl/dsi: Do not override TA_SURE
>
>Do not override
>-Original Message-
>From: Kulkarni, Vandita
>Sent: Tuesday, July 2, 2019 9:49 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: ville.syrj...@linux.intel.com; Nikula, Jani ;
>Shankar, Uma
>; Kulkarni, Vandita
>Subject: [PATCH 4/4] drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping
>
>N
On 15/07/2019 09:09, Chris Wilson wrote:
We cannot let the request be retired and freed while we are trying to
dump it during error capture. It is not sufficient just to grab a
reference to the request, as during retirement we may free the ring
which we are also dumping. So take the engine lock
On 15/07/2019 09:09, Chris Wilson wrote:
Trust that we now have adequate protection over the low level structures
via the engine->active.lock to allow ourselves to capture the GPU error
state without the heavy hammer of stop_machine(). Sadly this does mean
that we have to forgo some of the lesse
Quoting Tvrtko Ursulin (2019-07-16 11:48:28)
>
> On 15/07/2019 09:09, Chris Wilson wrote:
> > +/* single threaded page allocator with a reserved stash for emergencies */
> > +struct pool {
> > + void *stash[31];
>
> Why 31?
Random power-of-two. I considered just using struct pagevec.
>
> >
By stopping the rings, we may trigger an arbitration point resulting in
a premature context-switch (i.e. a completion event before the request
is actually complete). This clears the active context before the reset,
but we must remember to rewind the incomplete context for replay upon
resume.
Signe
Push the engine stop into the back reset_prepare (where it already was!)
This allows us to avoid dangerously setting the RING registers to 0 for
logical contexts. If we clear the register on a live context, those
invalid register values are recorded in the logical context state and
replayed (with h
As we unwind the requests for a preemption event, we return a virtual
request back to its original virtual engine (so that it is available for
execution on any of its siblings). In the process, this means that its
breadcrumb should no longer be associated with the original physical
engine, and so w
The shrinker cannot touch objects used by the contexts (logical state
and ring). Currently we mark those as "pin_global" to let the shrinker
skip over them, however, if we remove them from the shrinker lists
entirely, we don't event have to include them in our shrink accounting.
By keeping the uns
Following a try_to_unmap() we may want to remove the userptr and so call
put_pages(). However, try_to_unmap() acquires the page lock and so we
must avoid recursively locking the pages ourselves -- which means that
we cannot safely acquire the lock around set_page_dirty(). Since we
can't be sure of
== Series Details ==
Series: series starting with [1/5] drm/i915/userptr: Beware recursive
lock_page()
URL : https://patchwork.freedesktop.org/series/63752/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6492 -> Patchwork_13664
=
Am 26.06.19 um 14:29 schrieb Daniel Vetter:
On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called
On 2019-07-11 3:29 a.m., Pekka Paalanen wrote:
> Wait, one can write udev rules for connectors and stuff?
> How? What can they do?
I was using it to generate user-friendly device names for the mst aux
implementation:
https://patchwork.freedesktop.org/patch/315900/?series=63237&rev=2
Leo
___
Hi Rodrigo,
On Thu, Jul 11, 2019 at 11:44:35PM -0300, Rodrigo Siqueira wrote:
> On 07/10, Ser, Simon wrote:
> > Hi,
> >
> > Thanks for the patch! Here are a few comments.
> >
> > For bonus points, it would be nice to add igt_describe descriptions of
> > each sub-test.
>
> Hi Simon,
>
> First o
On 16/07/2019 13:49, Chris Wilson wrote:
Following a try_to_unmap() we may want to remove the userptr and so call
put_pages(). However, try_to_unmap() acquires the page lock and so we
must avoid recursively locking the pages ourselves -- which means that
we cannot safely acquire the lock around
On 12/07/2019 14.27, Chris Wilson wrote:
> Refactor the separate allocation routines into a single recursive
> function.
>
Reviewed-by: Abdiel Janulgue
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 272 ++--
> 1 file changed, 97 insertio
On 12/07/2019 14.27, Chris Wilson wrote:
> Refactor the separate allocation routines into a single recursive
> function.
>
Reviewed-by: Abdiel Janulgue
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 272 ++--
> 1 file changed, 97 insertion
On 12/07/2019 14.27, Chris Wilson wrote:
> Apply the new radix shift helpers to extract the multi-level indices
> cleanly when inserting pte into the gtt tree.
>
Reviewed-by: Abdiel Janulgue
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 115 +++--
Quoting Tvrtko Ursulin (2019-07-16 16:25:22)
>
> On 16/07/2019 13:49, Chris Wilson wrote:
> > Following a try_to_unmap() we may want to remove the userptr and so call
> > put_pages(). However, try_to_unmap() acquires the page lock and so we
> > must avoid recursively locking the pages ourselves --
Quoting Abdiel Janulgue (2019-07-16 16:30:09)
>
>
> On 12/07/2019 14.27, Chris Wilson wrote:
> > Apply the new radix shift helpers to extract the multi-level indices
> > cleanly when inserting pte into the gtt tree.
> >
> Reviewed-by: Abdiel Janulgue
Thanks for the reviews,
-Chris
== Series Details ==
Series: series starting with [1/5] drm/i915/userptr: Beware recursive
lock_page()
URL : https://patchwork.freedesktop.org/series/63752/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6492_full -> Patchwork_13664_full
===
Thanks Paul
Paul and James could you test this final solution(at least for 5.2)?
Please revert the hack patch and apply this one.
Thanks
On Mon, 2019-07-15 at 23:34 +0200, Paul Bolle wrote:
> Hi Jose,
>
> Souza, Jose schreef op ma 15-07-2019 om 21:03 [+]:
> > So the issue did not happened
From: Rob Clark
The driver should be in control of this.
Signed-off-by: Rob Clark
---
It is possible that this was masking bugs (ie. not setting appropriate
pgprot) in drivers. I don't have a particularly good idea for tracking
those down (since I don't have the hw for most drivers). Unless s
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 10 ++
drivers/gpu/drm/drm_gem_vram_helper.c | 6 --
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/etnaviv/
From: Rob Clark
Since there is no real device associated with VGEM, it is impossible to
end up with appropriate dev->dma_ops, meaning that we have no way to
invalidate the shmem pages allocated by VGEM. So, at least on platforms
without drm_cflush_pages(), we end up with corruption when cache li
On Mon, Jul 15, 2019 at 04:40:56PM -0700, Anusha Srivatsa wrote:
> DSC engine on ICL supports only 8 and 10 BPC as the input
> BPC. But DSC engine in TGL supports 8, 10 and 12 BPC.
> Add 12 BPC support for DSC while calculating compression
> configuration.
>
> v2: Remove the separate define TGL_DP
Quoting Rob Clark (2019-07-16 18:43:22)
> From: Rob Clark
>
> Needed in the following patch for cache operations.
What's the base for this patch? (I'm missing the ancestor for drm_gem.c)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Quoting Daniel Vetter (2019-07-16 10:21:54)
> On Fri, Jul 12, 2019 at 09:03:14AM +0100, Chris Wilson wrote:
> > As the set of shared fences is not being changed during reallocation of
> > the reservation list, we can skip updating the write_seqlock.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Dan
>-Original Message-
>From: Navare, Manasi D
>Sent: Tuesday, July 16, 2019 11:15 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
>
>Subject: Re: [PATCH] drm/dp/dsc: Add Support for all BPCs supported by TGL
>
>On Mon, Jul 15, 2019 at 04:40:56PM -0700, Anusha
On Fri, Jul 12, 2019 at 02:39:05PM +0300, Pekka Paalanen wrote:
> On Thu, 11 Jul 2019 10:18:22 -0400
> Sean Paul wrote:
>
> > On Mon, Jul 08, 2019 at 04:51:11PM +0530, Ramalingam C wrote:
> > > This patch adds a DRM ENUM property to the selected connectors.
> > > This property is used for mention
On Tue, Jul 16, 2019 at 01:26:19PM -0700, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Navare, Manasi D
> >Sent: Tuesday, July 16, 2019 11:15 AM
> >To: Srivatsa, Anusha
> >Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
> >
> >Subject: Re: [PATCH] drm/dp/dsc: Add Suppor
Avoid a global idle barrier by reconfiguring each context by rewriting
them with MI_STORE_DWORD from the kernel context.
v2: We only need to determine the desired register values once, they are
the same for all contexts.
v3: Don't remove the kernel context from the list of known GEM contexts;
the
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Lucas De Marchi
>Sent: Friday, July 12, 2019 6:09 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Mahesh Kumar
>Subject: [Intel-gfx] [PATCH 02/22] drm/i915/tgl: select correct bit for port
>
From: Rob Clark
The driver should be in control of this.
Signed-off-by: Rob Clark
---
It is possible that this was masking bugs (ie. not setting appropriate
pgprot) in drivers. I don't have a particularly good idea for tracking
those down (since I don't have the hw for most drivers). Unless s
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
v3: rebased on drm-tip
drivers/gpu/drm/drm_gem.c | 8
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers
From: Rob Clark
Since there is no real device associated with VGEM, it is impossible to
end up with appropriate dev->dma_ops, meaning that we have no way to
invalidate the shmem pages allocated by VGEM. So, at least on platforms
without drm_cflush_pages(), we end up with corruption when cache li
A single 32-bit PSR2 training pattern field follows the sixteen element
array of PSR table entries in the VBT spec. But, we incorrectly define
this PSR2 field for each of the PSR table entries. As a result, the PSR1
training pattern duration for any panel_type != 0 will be parsed
incorrectly. Secon
On Tue, 2019-07-16 at 15:03 -0700, Dhinakaran Pandiyan wrote:
> A single 32-bit PSR2 training pattern field follows the sixteen element
> array of PSR table entries in the VBT spec. But, we incorrectly define
> this PSR2 field for each of the PSR table entries. As a result, the PSR1
> training patt
== Series Details ==
Series: series starting with [v3,1/3] drm/gem: don't force writecombine mmap'ing
URL : https://patchwork.freedesktop.org/series/63770/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b6ec1673874e drm/gem: don't force writecombine mmap'ing
3e4afe6255ab drm: pl
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Lucas De Marchi
>Sent: Friday, July 12, 2019 6:09 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Mahesh Kumar
>Subject: [Intel-gfx] [PATCH 03/22] drm/i915/tgl: update ddi/tc clock_off bits
>
== Series Details ==
Series: drm/i915/oa: Reconfigure contexts on the fly (rev3)
URL : https://patchwork.freedesktop.org/series/63276/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6495 -> Patchwork_13665
Summary
---
== Series Details ==
Series: series starting with [v3,1/3] drm/gem: don't force writecombine mmap'ing
URL : https://patchwork.freedesktop.org/series/63770/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6495 -> Patchwork_13666
===
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Lucas De Marchi
>Sent: Friday, July 12, 2019 6:09 PM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 05/22] drm/i915/tgl: Update north display hotplug
>detection to TGL co
Rob Clark writes:
> From: Rob Clark
>
> The driver should be in control of this.
>
> Signed-off-by: Rob Clark
> ---
> It is possible that this was masking bugs (ie. not setting appropriate
> pgprot) in drivers. I don't have a particularly good idea for tracking
> those down (since I don't have
On Fri, 12 Jul 2019, Lucas De Marchi wrote:
> From: Michel Thierry
>
> Reuse Gen11 stolen memory changes since Tiger Lake uses the same BSM
> register (and format).
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Signed-off-by:
Rob Clark writes:
> From: Rob Clark
>
> Since there is no real device associated with VGEM, it is impossible to
> end up with appropriate dev->dma_ops, meaning that we have no way to
> invalidate the shmem pages allocated by VGEM. So, at least on platforms
> without drm_cflush_pages(), we end u
== Series Details ==
Series: drm/i915/oa: Reconfigure contexts on the fly (rev3)
URL : https://patchwork.freedesktop.org/series/63276/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6495_full -> Patchwork_13665_full
Summary
On Tue, Jul 16, 2019 at 4:39 PM Eric Anholt wrote:
>
> Rob Clark writes:
>
> > From: Rob Clark
> >
> > Since there is no real device associated with VGEM, it is impossible to
> > end up with appropriate dev->dma_ops, meaning that we have no way to
> > invalidate the shmem pages allocated by VGEM
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Lucas De Marchi
>Sent: Friday, July 12, 2019 6:09 PM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 06/22] drm/i915/tgl: handle DP aux interrupts
>
>For Tiger Lake the DE
On 07/12, Ser, Simon wrote:
> On Thu, 2019-07-11 at 23:44 -0300, Rodrigo Siqueira wrote:
> > On 07/10, Ser, Simon wrote:
> > > Hi,
> > >
> > > Thanks for the patch! Here are a few comments.
> > >
> > > For bonus points, it would be nice to add igt_describe descriptions of
> > > each sub-test.
> >
On Wed, Jul 17, 2019 at 12:46:42AM +0200, Thomas Gleixner wrote:
On Fri, 12 Jul 2019, Lucas De Marchi wrote:
From: Michel Thierry
Reuse Gen11 stolen memory changes since Tiger Lake uses the same BSM
register (and format).
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Pet
On 07/12, Ser, Simon wrote:
> On Thu, 2019-07-11 at 23:49 -0300, Rodrigo Siqueira wrote:
> > On 07/10, Ser, Simon wrote:
> > > On Wed, 2019-07-10 at 15:30 +, Ser, Simon wrote:
> > > > Mostly LGTM, here are a few nits.
> > > >
> > > > On Wed, 2019-06-12 at 23:17 -0300, Brian Starkey wrote:
> >
On 07/12, Ser, Simon wrote:
> So, to test these last two patches we'd need specific hardware right?
> Because VKMS doesn't support cloning yet (does it?).
hmmm... actually, VKMS successfully pass in this test. However, if you
compare "writeback-check-output" and "writeback-check-output-clone", you
On Wed, 10 Jul 2019 21:47:52 +0300
Ville Syrjälä wrote:
Hi Ville,
> On Wed, Jul 03, 2019 at 04:03:53PM -0700, Vivek Kasireddy wrote:
> > This patch adds support for DPLL4 on EHL that include the
> > following restrictions:
> >
> > - DPLL4 cannot be used with DDIA (combo port A internal eDP usage
Although, DPLL4 enable and disable is associated with MGPLL1_ENABLE
register, we can use ICL_DPLL_CFGCR0/CR1 macros to access this dpll's
CR0 and CR1 registers by passing an id of 4 to these macros.
Reported-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: José Roberto de Souza
Cc: Matt Roper
Cc: Imre
== Series Details ==
Series: drm/i915/ehl: Add support for DPLL4 (v10) (rev2)
URL : https://patchwork.freedesktop.org/series/63171/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6495 -> Patchwork_13667
Summary
---
**
== Series Details ==
Series: drm/i915/ehl: Add support for DPLL4 (v10) (rev2)
URL : https://patchwork.freedesktop.org/series/63171/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6495_full -> Patchwork_13667_full
Summary
---
On Tue, 16 Jul 2019, Lucas De Marchi wrote:
> On Wed, Jul 17, 2019 at 12:46:42AM +0200, Thomas Gleixner wrote:
> > On Fri, 12 Jul 2019, Lucas De Marchi wrote:
> >
> > > From: Michel Thierry
> > >
> > > Reuse Gen11 stolen memory changes since Tiger Lake uses the same BSM
> > > register (and forma
Am 16.07.19 um 23:37 schrieb Rob Clark:
> From: Rob Clark
>
> Needed in the following patch for cache operations.
Well have you seen that those callbacks are deprecated?
>* Deprecated hook in favour of &drm_gem_object_funcs.pin.
>* Deprecated hook in favour of &drm_gem_object_fun
64 matches
Mail list logo
