Hi Michel,
Thanks for your answer, I just enabled the debug and captured a drm debug log
from dmesg, but I don't seem to find anything that looks like an
error, Is there anything specific I should be looking for?
Sorry for attaching my log here, here is the last drmModeAtomicCommit
where I had -e
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> Add back our standalone i915_buddy allocator and integrate it into a
> ttm_resource_manager. This will plug into our ttm backend for
> managing
> device local-memory in the next couple of patches.
>
> Signed-off-by: Matthew Auld
> Cc: Thoma
Am 08.06.21 um 07:29 schrieb Thomas Hellström (Intel):
Hi,
On 6/7/21 7:59 PM, Christian König wrote:
Am 07.06.21 um 19:58 schrieb Thomas Hellström (Intel):
On 6/7/21 7:54 PM, Christian König wrote:
Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):
On 6/7/21 6:40 PM, Thomas Hellstr
Hi,
On 6/8/21 9:14 AM, Christian König wrote:
Am 08.06.21 um 07:29 schrieb Thomas Hellström (Intel):
Hi,
On 6/7/21 7:59 PM, Christian König wrote:
Am 07.06.21 um 19:58 schrieb Thomas Hellström (Intel):
On 6/7/21 7:54 PM, Christian König wrote:
Am 07.06.21 um 19:06 schrieb Thomas Hellst
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> We need to be able to build an sg table from our list of buddy
> blocks,
> so that we can later plug this into our ttm backend, and replace our
> use
> of the range manager.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
Not sure
Am 08.06.21 um 09:17 schrieb Thomas Hellström (Intel):
[SNIP]
Do you have the log to double check?
Unfortunately not, but IIRC it was directly from vmw_move().
Nirmoy do you still have your vmwgfx test environment?
Thanks,
Christian.
/Thomas
Hi,
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
> fine since everything is already contiguous with the ttm range
> manager.
> However in the next patch we want to switch over to the ttm buddy
> manager, where allocat
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> Move back to the buddy allocator for managing device local memory,
> and
> restore the lost mock selftests. Keep around the range manager
> related
> bits, since we likely need this for managing stolen at some point.
> For
> stolen we also do
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> Move back to the buddy allocator for managing device local memory,
> and
> restore the lost mock selftests. Keep around the range manager
> related
> bits, since we likely need this for managing stolen at some point.
> For
> stolen we also do
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> We now have bo->page_alignment which perfectly describes what we need
> if
> we have min page size restrictions for lmem. We can also drop the
> flag
> here, since this is the default behaviour for all objects.
>
> Signed-off-by: Matthew Aul
We need to make sure to allocate the sys_mem resource before the point
of no return.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/d
On Mon, 7 Jun 2021 18:07:23 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: dri-devel On Behalf Of Pekka
> > Paalanen
> > Sent: Monday, June 7, 2021 1:00 PM
> > To: Harry Wentland
> > Cc: intel-...@lists.freedesktop.org; Shankar, Uma ;
> > Sebastian Wick ;
> > dri-devel@li
On 08.06.2021 00:46, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> New GuC firmware will unify format of MMIO and CTB H2G messages.
>> Introduce their definitions now to allow gradual transition of
>> our code to match new chang
On 08/06/2021 08:26, Thomas Hellström wrote:
Hi,
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
fine since everything is already contiguous with the ttm range
manager.
However in the next patch we want to switch over t
Hi,
On 07/06/2021 19:42, Marek Vasut wrote:
> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
> and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
> bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
> but easy to add.
>
> The driver o
On 08/06/2021 08:11, Thomas Hellström wrote:
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
Add back our standalone i915_buddy allocator and integrate it into a
ttm_resource_manager. This will plug into our ttm backend for
managing
device local-memory in the next couple of patches.
Sign
On 6/8/21 9:50 AM, Christian König wrote:
We need to make sure to allocate the sys_mem resource before the point
of no return.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/dr
On 08/06/2021 08:39, Thomas Hellström wrote:
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
Move back to the buddy allocator for managing device local memory,
and
restore the lost mock selftests. Keep around the range manager
related
bits, since we likely need this for managing stolen at
On 08.06.2021 01:06, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> The MMIO based Host-to-GuC communication protocol has been
>> updated to use unified HXG messages.
>>
>> Update our intel_guc_send_mmio() function by correctly h
On 6/8/21 10:11 AM, Matthew Auld wrote:
On 08/06/2021 08:11, Thomas Hellström wrote:
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
Add back our standalone i915_buddy allocator and integrate it into a
ttm_resource_manager. This will plug into our ttm backend for
managing
device local-
We need to make sure to allocate the sys_mem resource before the point
of no return.
v2: add missing return value checking, also handle idle case
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 28
1 file changed, 20 insertions(+), 8 deletions
Hi Neil,
On Tue, Jun 08, 2021 at 10:10:05AM +0200, Neil Armstrong wrote:
> On 07/06/2021 19:42, Marek Vasut wrote:
> > Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
> > and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
> > bridge. TI SN65DSI85 is unsuppo
On 6/8/21 10:19 AM, Christian König wrote:
We need to make sure to allocate the sys_mem resource before the point
of no return.
v2: add missing return value checking, also handle idle case
Signed-off-by: Christian König
lgtm.
Reviewed-by: Thomas Hellström
On 08.06.2021 02:05, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> Format of the STATUS dword in CTB response message now follows
>> definition of the HXG header. Update our code and remove any
>> obsolete legacy definitions.
>
On Mon, 7 Jun 2021 17:34:06 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Harry Wentland
> > Sent: Friday, June 4, 2021 11:54 PM
> > To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> > dri-
> > de...@lists.freedesktop.org
> > Cc: Modem, Bhanuprakash ; Cyr, Aric
> >
>
On 07/06/2021 18:31, Matthew Brost wrote:
On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
On 27/05/2021 15:35, Matthew Brost wrote:
On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
On 26/05/2021 19:10, Matthew Brost wrote:
[snip]
+static int ct_send_nb(str
Needs to be applied on top of:
https://patchwork.freedesktop.org/series/90681/
Matthew Auld (5):
drm/i915/ttm: add ttm_buddy_man
drm/i915/ttm: add i915_sg_from_buddy_resource
drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS
drm/i915/ttm: switch over to ttm_buddy_man
drm/i915/ttm: re
Add back our standalone i915_buddy allocator and integrate it into a
ttm_resource_manager. This will plug into our ttm backend for managing
device local-memory in the next couple of patches.
v2(Thomas):
- Return -ENOSPC from the buddy; ttm expects this in order to
trigger eviction
-
We need to be able to build an sg table from our list of buddy blocks,
so that we can later plug this into our ttm backend, and replace our use
of the range manager.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_scatterlist.c | 80
From: Thomas Hellström
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That well be added later.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/g
Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
fine since everything is already contiguous with the ttm range manager.
However in the next patch we want to switch over to the ttm buddy
manager, where allocations are by default not contiguous.
v2(Thomas):
- Forward ALLOC_C
Move back to the buddy allocator for managing device local memory, and
restore the lost mock selftests. Keep around the range manager related
bits, since we likely need this for managing stolen at some point. For
stolen we also don't need to reserve anything so no need to support a
generic reserve
We now have bo->page_alignment which perfectly describes what we need if
we have min page size restrictions for lmem. We can also drop the flag
here, since this is the default behaviour for all objects.
v2(Thomas):
- bo->page_alignment is in page units
Signed-off-by: Matthew Auld
Cc: Thomas
On Tue, Jun 8, 2021 at 10:39 AM Tvrtko Ursulin
wrote:
>
>
> On 07/06/2021 18:31, Matthew Brost wrote:
> > On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 27/05/2021 15:35, Matthew Brost wrote:
> >>> On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
>
Hey Neil,
On Tue, 8 Jun 2021 at 10:10, Neil Armstrong wrote:
>
> Hi,
>
> On 07/06/2021 19:42, Marek Vasut wrote:
> > Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
> > and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
> > bridge. TI SN65DSI85 is unsuppor
In vc4_atomic_commit_tail() we iterate of the set of old CRTCs, and
attempt to wait on any channels which are still in use. When we iterate
over the CRTCs, we have:
* `i` - the index of the CRTC
* `channel` - the channel a CRTC is using
When we check the channel state, we consult:
old_hvs_stat
On Mon, Jun 07, 2021 at 05:50:57PM +0200, Arnd Bergmann wrote:
> On Mon, Jun 7, 2021 at 5:17 PM Maxime Ripard wrote:
> > On Mon, Jun 07, 2021 at 03:57:41PM +0200, Arnd Bergmann wrote:
> > > On Mon, Jun 7, 2021 at 3:39 PM Will Deacon wrote:
> > > > On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Ru
Replace the IRQ check in VBLANK ioctls with a check for vblank
support. IRQs might be enabled wthout vblanking being supported.
This change also removes the DRM framework's only dependency on
IRQ state for non-legacy drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_irq.c| 1
Hi
Am 07.06.21 um 17:13 schrieb Deepak Rawat:
On Thu, 2021-05-27 at 15:35 +0200, Thomas Zimmermann wrote:
Hi
if no further comments come in, this can be moved in a few days.
Since
you'll be the maintainer, you should request commit access to the
drm-misc repository. See
https://drm.pages
On Tue, Jun 8, 2021 at 10:56 AM Mark Rutland wrote:
>
> In vc4_atomic_commit_tail() we iterate of the set of old CRTCs, and
> attempt to wait on any channels which are still in use. When we iterate
> over the CRTCs, we have:
>
> * `i` - the index of the CRTC
> * `channel` - the channel a CRTC is u
On Tue, Jun 08, 2021 at 11:03:01AM +0200, Thomas Zimmermann wrote:
> Replace the IRQ check in VBLANK ioctls with a check for vblank
> support. IRQs might be enabled wthout vblanking being supported.
Nah, or if they are, that's a broken driver. irq_enabled here really only
means vblank_irq_enabled
On Tue, Jun 8, 2021 at 11:18 AM Daniel Vetter wrote:
>
> On Tue, Jun 08, 2021 at 11:03:01AM +0200, Thomas Zimmermann wrote:
> > Replace the IRQ check in VBLANK ioctls with a check for vblank
> > support. IRQs might be enabled wthout vblanking being supported.
>
> Nah, or if they are, that's a brok
A couple of patches from Chris which implement pipelined migration and
clears by atomically writing the PTEs in place before performing the
actual blit.
Some ww utilities mainly for the accompanying selftests added by Thomas,
as well as modified the above patches for ww locking- and lmem support.
Since the ww transaction endpoint easily end up far out-of-scope of
the objects on the ww object list, particularly for contending lock
objects, make sure we reference objects on the list so they don't
disappear under us.
This comes with a performance penalty so it's been debated whether this
is r
As we're about to add more ww-related functionality,
break out the dma_resv ww locking utilities to their own files
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
drivers/gpu/drm/i915/gt/intel_renderstat
Introduce a for_i915_gem_ww(){} utility to help make the code
around a ww transaction more readable.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_gem_ww.h | 31 +-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915
From: Chris Wilson
In the next patch, we will want to look at the dma addresses of
individual page tables, so add a routine to iterate over them.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 49
drivers/gpu/drm/i915/gt/intel_gtt.h | 7 ++
From: Chris Wilson
Allow internal clients to create a pinned context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h| 9 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 21 ++---
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/
From: Chris Wilson
In the next patch, we will want to write a PTE for an explicit
dma address, outside of the usual vma.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/gen8_pp
From: Chris Wilson
If we pipeline the PTE updates and then do the copy of those pages
within a single unpreemptible command packet, we can submit the copies
and leave them to be scheduled without having to synchronously wait
under a global lock. In order to manage migration, we need to
preallocat
From: Chris Wilson
Update the PTE and emit a clear within a single unpreemptible packet
such that we can schedule and pipeline clears.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_migrate.c| 141 ++
From: Chris Wilson
Set up a default migration context on the GT and use it from the
selftests.
Add a perf selftest and make sure we exercise LMEM if available.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gt.c
On 6/8/21 10:51 AM, Robert Foss wrote:
Hey Neil,
On Tue, 8 Jun 2021 at 10:10, Neil Armstrong wrote:
Hi,
On 07/06/2021 19:42, Marek Vasut wrote:
Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
bridge.
On 6/8/2021 9:21 AM, Christian König wrote:
Am 08.06.21 um 09:17 schrieb Thomas Hellström (Intel):
[SNIP]
Do you have the log to double check?
Unfortunately not, but IIRC it was directly from vmw_move().
Nirmoy do you still have your vmwgfx test environment?
Yes!
Thanks,
Christia
Hi Christian,
I based amdgpu_preempt_mgr on amdgpu_gtt_mgr and now I'm looking at what
changed there. Looks like I'll need to create a dummy node in
amdgpu_preempt_mgr_new to satisfy TTM, and free it in
amdgpu_preempt_mgr_del.
Thanks,
Felix
Am 2021-06-07 um 10:50 p.m. schrieb Stephen Rothwell
On 6/8/2021 11:38 AM, Das, Nirmoy wrote:
On 6/8/2021 9:21 AM, Christian König wrote:
Am 08.06.21 um 09:17 schrieb Thomas Hellström (Intel):
[SNIP]
Do you have the log to double check?
Unfortunately not, but IIRC it was directly from vmw_move().
Nirmoy do you still have your vmwgfx tes
Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
Reviewed-by: Linus Walleij
Reviewed-by: Rob Herring
Signed-off-by: Marek Vasut
Cc: Douglas Anderson
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: Stephen Boyd
Cc: devic
Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge
and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS
bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on,
but easy to add.
The driver operates the chip via I2C bus. Currently the LVDS clock ar
Am 08.06.21 um 11:40 schrieb Das, Nirmoy:
On 6/8/2021 11:38 AM, Das, Nirmoy wrote:
On 6/8/2021 9:21 AM, Christian König wrote:
Am 08.06.21 um 09:17 schrieb Thomas Hellström (Intel):
[SNIP]
Do you have the log to double check?
Unfortunately not, but IIRC it was directly from vmw_move(
On Tue, 8 Jun 2021 at 11:34, Marek Vasut wrote:
>
> On 6/8/21 10:51 AM, Robert Foss wrote:
> > Hey Neil,
> >
> > On Tue, 8 Jun 2021 at 10:10, Neil Armstrong wrote:
> >>
> >> Hi,
> >>
> >> On 07/06/2021 19:42, Marek Vasut wrote:
> >>> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS
On 08.06.2021 10:55, Mark Rutland wrote:
> In vc4_atomic_commit_tail() we iterate of the set of old CRTCs, and
> attempt to wait on any channels which are still in use. When we iterate
> over the CRTCs, we have:
>
> * `i` - the index of the CRTC
> * `channel` - the channel a CRTC is using
>
> Whe
On 6/8/21 11:42 AM, Robert Foss wrote:
On Tue, 8 Jun 2021 at 11:34, Marek Vasut wrote:
On 6/8/21 10:51 AM, Robert Foss wrote:
Hey Neil,
On Tue, 8 Jun 2021 at 10:10, Neil Armstrong wrote:
Hi,
On 07/06/2021 19:42, Marek Vasut wrote:
Add driver for TI SN65DSI83 Single-link DSI to Single-li
Pushed to drm-misc-next.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=db2aad0ffa7dfec31ddf715017a6ae57aa162045
On Tue, 8 Jun 2021 at 11:42, Robert Foss wrote:
>
> On Tue, 8 Jun 2021 at 11:34, Marek Vasut wrote:
> >
> > On 6/8/21 10:51 AM, Robert Foss wrote:
> > > Hey Neil,
> > >
> > > O
On 6/8/21 11:44 AM, Robert Foss wrote:
Pushed to drm-misc-next.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=db2aad0ffa7dfec31ddf715017a6ae57aa162045
Well, then I'll just send a follow up patch.
On Tue, 8 Jun 2021 at 11:45, Marek Vasut wrote:
>
> On 6/8/21 11:44 AM, Robert Foss wrote:
> > Pushed to drm-misc-next.
> >
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=db2aad0ffa7dfec31ddf715017a6ae57aa162045
>
> Well, then I'll just send a follow up patch.
Thank you!
On 6/8/21 10:44 AM, Matthew Auld wrote:
Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
fine since everything is already contiguous with the ttm range manager.
However in the next patch we want to switch over to the ttm buddy
manager, where allocations are by default not co
On 6/8/2021 11:42 AM, Christian König wrote:
Am 08.06.21 um 11:40 schrieb Das, Nirmoy:
On 6/8/2021 11:38 AM, Das, Nirmoy wrote:
On 6/8/2021 9:21 AM, Christian König wrote:
Am 08.06.21 um 09:17 schrieb Thomas Hellström (Intel):
[SNIP]
Do you have the log to double check?
Unfortunate
On 6/8/21 10:44 AM, Matthew Auld wrote:
We now have bo->page_alignment which perfectly describes what we need if
we have min page size restrictions for lmem. We can also drop the flag
here, since this is the default behaviour for all objects.
v2(Thomas):
- bo->page_alignment is in page un
On 6/8/21 10:44 AM, Matthew Auld wrote:
Move back to the buddy allocator for managing device local memory, and
restore the lost mock selftests. Keep around the range manager related
bits, since we likely need this for managing stolen at some point. For
stolen we also don't need to reserve anyth
Fix ./scripts/checkpatch.pl --strict -f drivers/gpu/drm/bridge/ti-sn65dsi83.c
CHECKs, no functional change. This is the same modification done to V7 of the
original patch.
Signed-off-by: Marek Vasut
Cc: Adam Ford
Cc: Douglas Anderson
Cc: Frieder Schrempf
Cc: Jagan Teki
Cc: Laurent Pinchart
C
On 6/8/21 11:45 AM, Robert Foss wrote:
On Tue, 8 Jun 2021 at 11:45, Marek Vasut wrote:
On 6/8/21 11:44 AM, Robert Foss wrote:
Pushed to drm-misc-next.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=db2aad0ffa7dfec31ddf715017a6ae57aa162045
Well, then I'll just send a follow up patch.
On 02/06/2021 13:00, Thomas Hellström wrote:
Hi,
On 6/2/21 11:36 AM, Matthew Auld wrote:
For dgfx where we now have lmem and ttm, we can only support single mmap
mode for the lifetime of the object, and for lmem objects this should be
WC, so reject all other mapping modes for mmap_offset, inclu
On Tue, 2021-06-08 at 10:57 +0100, Matthew Auld wrote:
> On 02/06/2021 13:00, Thomas Hellström wrote:
> > Hi,
> >
> > On 6/2/21 11:36 AM, Matthew Auld wrote:
> > > For dgfx where we now have lmem and ttm, we can only support
> > > single mmap
> > > mode for the lifetime of the object, and for lmem
On Thu, 2021-05-20 at 17:03 +0200, Maxime Ripard wrote:
> From: Mateusz Kwiatkowski
>
> The BCM2711 has a slightly different VEC than the one found in the older
> SoCs. Now that we support the new variant, add its compatible to the
> device tree.
>
> Signed-off-by: Mateusz Kwiatkowski
> Signed-
On 08/06/2021 10:53, Thomas Hellström wrote:
On 6/8/21 10:44 AM, Matthew Auld wrote:
Move back to the buddy allocator for managing device local memory, and
restore the lost mock selftests. Keep around the range manager related
bits, since we likely need this for managing stolen at some point. F
On Tue, 2021-06-08 at 11:08 +0100, Matthew Auld wrote:
> On 08/06/2021 10:53, Thomas Hellström wrote:
> >
> > On 6/8/21 10:44 AM, Matthew Auld wrote:
> > > Move back to the buddy allocator for managing device local
> > > memory, and
> > > restore the lost mock selftests. Keep around the range mana
Thanks for submitting this.
Fix ./scripts/checkpatch.pl --strict -f drivers/gpu/drm/bridge/ti-sn65dsi83.c
CHECKs, no functional change. This is the same modification done to V7 of the
original patch.
Signed-off-by: Marek Vasut
Cc: Adam Ford
Cc: Douglas Anderson
Cc: Frieder Schrempf
Cc: Jagan
The backlight_ops.update_status function is required to return a
negative error code on failure. Returning a positive code may be
interpreted as a success. This is true for the 'brightness' sysfs file,
which passes through a non-zero value as the return value of the write()
syscall. This is interpr
Kind reminder. Deadline is Sunday, 4 July 2021 :-)
Sam
On Thu, 2021-05-20 at 10:01 +, Szwichtenberg, Radoslaw wrote:
> Hello!
>
> Registration & Call for Proposals are now open for XDC 2021, which
> will
> take place on September 15-17, 2021. This year we will repeat as
> virtual event.
>
On 08/06/2021 04:28, abhin...@codeaurora.org wrote:
On 2021-06-07 16:00, Dmitry Baryshkov wrote:
Unlike previous generations, 7nm PHYs are required to collaborate with
the host for conitnuos clock mode. Add changes neccessary to enable
"the host for continuous clock mode"
Thanks!
continuous
Hello,
syzbot found the following issue on:
HEAD commit:f88cd3fb Merge tag 'vfio-v5.13-rc5' of git://github.com/aw..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=126f13b030
kernel config: https://syzkaller.appspot.com/x/.config?x=ad5040c83f09b8e4
das
Hi Felix,
that should already be fixed in drm-tip as part of the merge of the TTM
changes.
Regards,
Christian.
Am 08.06.21 um 07:37 schrieb Felix Kuehling:
Hi Christian,
I based amdgpu_preempt_mgr on amdgpu_gtt_mgr and now I'm looking at what
changed there. Looks like I'll need to create a
Needs to be applied on top of:
https://patchwork.freedesktop.org/series/90681/
Matthew Auld (6):
drm/i915/ttm: add ttm_buddy_man
drm/i915/ttm: add i915_sg_from_buddy_resource
drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS
drm/i915/ttm: remove node usage in our naming
drm/i915/ttm:
Add back our standalone i915_buddy allocator and integrate it into a
ttm_resource_manager. This will plug into our ttm backend for managing
device local-memory in the next couple of patches.
v2(Thomas):
- Return -ENOSPC from the buddy; ttm expects this in order to
trigger eviction
-
We need to be able to build an sg table from our list of buddy blocks,
so that we can later plug this into our ttm backend, and replace our use
of the range manager.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_scatterlist.c | 80
From: Thomas Hellström
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That well be added later.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/g
Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
fine since everything is already contiguous with the ttm range manager.
However in the next patch we want to switch over to the ttm buddy
manager, where allocations are by default not contiguous.
v2(Thomas):
- Forward ALLOC_C
Now that ttm_resource_manager just returns a generic ttm_resource we
don't need to reference the mm_node stuff anymore which mostly only
makes sense for drm_mm_node. In the next few patches we want switch over
to the ttm_buddy_man which is just another type of ttm_resource so
reflect that in the na
Move back to the buddy allocator for managing device local memory, and
restore the lost mock selftests. Keep around the range manager related
bits, since we likely need this for managing stolen at some point. For
stolen we also don't need to reserve anything so no need to support a
generic reserve
We now have bo->page_alignment which perfectly describes what we need if
we have min page size restrictions for lmem. We can also drop the flag
here, since this is the default behaviour for all objects.
v2(Thomas):
- bo->page_alignment is in page units
Signed-off-by: Matthew Auld
Cc: Thomas
Looks good for me.
Reviewed-by: Huang Rui
-Original Message-
From: Christian König
Sent: Monday, June 7, 2021 8:52 PM
To: dri-devel@lists.freedesktop.org; Pan, Xinhui ; Das,
Nirmoy ; Huang, Ray
Cc: Thomas Hellström
Subject: Re: [PATCH] drm/ttm: fix deref of bo->ttm without holding t
Am 2021-06-08 um 2:55 a.m. schrieb Christian König:
> Hi Felix,
>
> that should already be fixed in drm-tip as part of the merge of the
> TTM changes.
No, the preempt_mgr doesn't exist in drm-misc-next. It does exist in
drm-next, but that doesn't seem to have the TTM changes yet.
Is there another
Hi
Am 08.06.21 um 11:23 schrieb Daniel Vetter:
On Tue, Jun 8, 2021 at 11:18 AM Daniel Vetter wrote:
On Tue, Jun 08, 2021 at 11:03:01AM +0200, Thomas Zimmermann wrote:
Replace the IRQ check in VBLANK ioctls with a check for vblank
support. IRQs might be enabled wthout vblanking being supporte
On Wed, Jun 02, 2021 at 09:52:44AM -0700, Rob Clark wrote:
> From: Jordan Crouse
>
> Call report_iommu_fault() to allow upper-level drivers to register their
> own fault handlers.
>
> Signed-off-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 +++
Am 08.06.21 um 09:06 schrieb Felix Kuehling:
Am 2021-06-08 um 2:55 a.m. schrieb Christian König:
Hi Felix,
that should already be fixed in drm-tip as part of the merge of the
TTM changes.
No, the preempt_mgr doesn't exist in drm-misc-next. It does exist in
drm-next, but that doesn't seem to ha
The V3D engine has several hardware performance counters that can of
interest for userspace performance analysis tools.
This exposes new ioctls to create and destroy performance monitor
objects, as well as to query the counter values.
Each created performance monitor object has an ID that can be
On Fri, 26 Mar 2021 16:13:02 -0700, Eric Anholt wrote:
> db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> the GPU from wedging and then sometimes wedging the kernel after a
> page fault), but it doesn't have separate pagetables support yet in
> drm/msm so we can't go all the w
g git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-fix-pipelined-gutting/20210608-155139
base: git://anongit.free
convert list_for_each() to list_for_each_entry() where
applicable.
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/video/fbdev/core/fbsysfs.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/core/fbsysfs.c
b/drivers/video/fbdev/core/fbs
On Tue, 2021-06-08 at 12:02 +0100, Matthew Auld wrote:
> Now that ttm_resource_manager just returns a generic ttm_resource we
> don't need to reference the mm_node stuff anymore which mostly only
> makes sense for drm_mm_node. In the next few patches we want switch
> over
> to the ttm_buddy_man whi
1 - 100 of 244 matches
Mail list logo
