On launchpad they requested to report this bug upstream. Please let me know
if any information is missing.
[1.] One line summary of the problem:
Display resolutions missing on external VGA display [regressing]
[2.] Full description of the problem/report:
The bug description can be found at:
http
bmits is used' is not
valid English.
It also seems that the idea of splitting all the deletes of old code
into a separate patch didn't happen. It really does obfuscate things
significantly having completely unrelated deletes and adds interspersed :(.
John.
Also the per engine in
: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 22 +-
drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 1 -
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 40 ++
drivers/gpu/drm/i915/gt/uc
On 7/19/2021 15:55, Matthew Brost wrote:
On Mon, Jul 19, 2021 at 04:01:56PM -0700, John Harrison wrote:
On 7/16/2021 13:16, Matthew Brost wrote:
Implement GuC submission tasklet for new interface. The new GuC
interface uses H2G to submit contexts to the GuC. Since H2G use a single
channel, a
i915 so another reason to not enable
these for GuC submission.
This patch fixes an existing bug where I915_ENGINE_HAS_SEMAPHORES was
not honored correctly.
Bugs plural. Otherwise:
Reviewed-by: John Harrison
v2: Reword commit message
v3:
(John H)
- Add text to commit indicating this also
.
v2: rtimeout -> remaining_timeout
v3: Drop unnecessary includes, guc_submission_busy_loop ->
guc_submission_send_busy_loop, drop negatie timeout trick, move a
refactor of guc_context_unpin to earlier path (John H)
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/d
On 7/16/2021 13:16, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
v2:
(John Harrison)
- Remove intel_lrc_reg.h include from i915_debugfs.c
(Michal)
- Rename GuC debugfs functions
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by
addressed.
John.
and ring tail value.
v2: Fix white space alignment in i915_request_add trace point
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++
drivers/gpu/drm/i915/i915_request.c | 3
On 7/16/2021 13:16, Matthew Brost wrote:
From: John Harrison
The serial number tracking of engines happens at the backend of
request submission and was expecting to only be given physical
engines. However, in GuC submission mode, the decomposition of virtual
to physical engines does not happen
class when using GuC submission and
direct all physical engine interrupts to this breadcrumbs.
v2:
(John H)
- Rework header file structure so intel_engine_mask_t can be in
intel_engine_types.h
Signed-off-by: Matthew Brost
CC: John Harrison
Reviewed-by: John Harrison
---
drive
On 7/19/2021 18:53, Matthew Brost wrote:
On Mon, Jul 19, 2021 at 06:03:05PM -0700, John Harrison wrote:
On 7/16/2021 13:16, Matthew Brost wrote:
When running the GuC the GPU can't be considered idle if the GuC still
has contexts pinned. As such, a call has been added in
intel_gt_wait_for
o not leak stuff and/or dereference null pointers!
Either way...
Reviewed-by: John Harrison
destroyed.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_scheduler.c | 3 ++-
drivers/gpu/drm/i915/i915_scheduler.h | 4 +---
drivers/gpu/drm/i915/i915_scheduler_type
On 7/16/2021 13:16, Matthew Brost wrote:
Move active request tracking to a backend vfunc rather than assuming all
backends want to do this in the maner. In the case execlists /
maner -> manner.
In the case *of* execlists
With those fixed...
Reviewed-by: John Harrison
ring submission
(CT deadlock/corrupt check)
v3:
(John H)
- Split into a series of smaller patches
While the split happened, it doesn't look like any of the other comments
were address. Repeated below for clarity. Also, Tvrtko has a bunch of
outstanding comments too.
Cc: John Harrison
Signed-o
On 7/16/2021 13:17, Matthew Brost wrote:
GuC will issue a reset on detecting an engine hang and will notify
the driver via a G2H message. The driver will service the notification
by resetting the guilty context to a simple state or banning it
completely.
v2:
(John Harrison)
- Move msg[0
On 7/16/2021 13:17, Matthew Brost wrote:
When using GuC submission, if a context gets banned disable scheduling
and mark all inflight requests as complete.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2
On 7/16/2021 13:17, Matthew Brost wrote:
Requests may take slightly longer with GuC submission, let's increase
the timeouts in live_requests.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/selftests/i915_request.c | 4 ++--
1 file changed, 2 inser
disable the
rescheduling of the physical engine tasklet, when using GuC scheduling,
as the physical engine tasklet is no longer used.
In this patch the field, guc_id, has been added to intel_context and is
not assigned. Patches later in the series will assign this value.
v2:
(John Harrison
Brost)
- Drop GUC_ID_START
(John Harrison)
- Fix a bunch of typos
- Use drm_err rather than drm_dbg for G2H errors
(Daniele)
- Fix ;; typo
- Clean up sched state functions
- Add lockdep for guc_id functions
- Don't call __release_guc_id when guc_id is invalid
rior to f8f934c180f629bb927a04fd90d)
>
> Reported-by: Dmitry Baryshkov
> Reported-by: Yassine Oudjana
> Fixes: 2a574cc05d38 ("drm/msm: Improve the a6xx page fault handler")
> Signed-off-by: Rob Clark
> Tested-by: John Stultz
> ---
Hey folks!
Just wanted to follow u
(CT deadlock/corrupt check)
v3:
(John H)
- Split into a series of smaller patches
v4:
(John H)
- Fix typo
- Add braces around if statements in reset code
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c
On 7/27/2021 02:49, Daniel Vetter wrote:
On Mon, Jul 26, 2021 at 07:21:43PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be
On 7/26/2021 17:23, Matthew Brost wrote:
Requests may take slightly longer with GuC submission, let's increase
the timeouts in live_requests.
Signed-off-by: Matthew Brost
Was already reviewed in previous series. Repeating here for patchwork:
Reviewed-by: John Harrison
---
drivers/gp
ts. No back end
scheduler hacks required and no intimate knowledge of the i915 heartbeat
mechanism required either.
John.
This patch also updates intel_engine_has_heartbeat to be a vfunc as we
now need to call this function on execlists virtual engines too.
Signed-off-by: Matthew Brost
---
drive
That said, there still are some references to it:
https://cs.android.com/android/platform/superproject/+/master:system/core/libsync/sync.c;l=416
But it looks like the actual users are only kselftest and igt?
Adding Alistair, Hridya and Sandeep in case they have more context.
thanks
-john
On 7/30/2021 02:49, Tvrtko Ursulin wrote:
On 30/07/2021 01:13, John Harrison wrote:
On 7/28/2021 17:34, Matthew Brost wrote:
If an engine associated with a context does not have a heartbeat,
ban it
immediately. This is needed for GuC submission as a idle pulse doesn't
kick the context of
allocation limits.
Reviewed-by: John Stultz
thanks
-john
the CRTC's
> atomic_check() should be adding the planes to the atomic update.
Thanks! This patch gets things booting again!
Tested-by: John Stultz
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 8/2/2021 02:40, Tvrtko Ursulin wrote:
On 30/07/2021 19:13, John Harrison wrote:
On 7/30/2021 02:49, Tvrtko Ursulin wrote:
On 30/07/2021 01:13, John Harrison wrote:
On 7/28/2021 17:34, Matthew Brost wrote:
If an engine associated with a context does not have a heartbeat,
ban it
immediately
meline_exit which could result in the syncmap not getting
+* free'd. Rather than work to hard to seal this race, simply cleanup
+* the syncmap on fini.
What is the race? I'm going round in circles just trying to work out how
intel_gt_retire_requests_timeout is supposed to g
ding on gen12+ aside from TGL, RKL, and ADL_S not
allowed\n");
I would have said not supported rather than not allowed. Either way:
Reviewed-by: John Harrison
+ return -ENODEV;
+ }
+
if (get_user(idx, &ext->virtual_index))
return -EFAULT;
handling, must be atomic [no fs_reclaim] */
GEM_BUG_ON(!intel_uc_fw_is_available(uc_fw));
- return sg_pcopy_to_buffer(pages->sgl, pages->nents, dst, size, offset);
+ idx = offset >> PAGE_SHIFT;
+ offset = offset_in_page(offset);
+ if (i915_gem_obje
, 0, 0), huc_def(tgl, 7, 9, 3)) \
fw_def(JASPERLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
Reviewed-by: John Harrison
)) {
+ if (IS_ALDERLAKE_S(i915)) {
i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
return;
}
Reviewed-by: John Harrison
On 8/6/2021 11:29, Matthew Brost wrote:
On Fri, Aug 06, 2021 at 11:23:06AM -0700, John Harrison wrote:
On 7/30/2021 12:53, Matthew Brost wrote:
A small race exists between intel_gt_retire_requests_timeout and
intel_timeline_exit which could result in the syncmap not getting
free'd. Rather
On 8/6/2021 12:46, Daniel Vetter wrote:
Seen this fly by and figured I dropped a few thoughts in here. At the
likely cost of looking a bit out of whack :-)
On Fri, Aug 6, 2021 at 8:01 PM John Harrison wrote:
On 8/2/2021 02:40, Tvrtko Ursulin wrote:
On 30/07/2021 19:13, John Harrison wrote
should I be going about getting some more planes to use for
overlays? Pointers to documentation / examples gratefully received - so
far my google-foo has failed to find anything that works.
I'm sorry if this is the wrong place to ask, but if there is a better
place please say and I'll go there.
Many thanks
John Cox
>On Tue, Aug 10, 2021 at 05:57:31PM +0100, John Cox wrote:
>> Hi all
>>
>> I am on a Raspberry Pi, I want to display fullscreen video and have a
>> couple of overlay planes to display controls / subtitles etc. The h/w
>> can certainly do this. I need to b
>events. Letting the compositor deal with KMS planes is the preferred
>approach.
If that can be made to work then I agree I would like to do it like
that.
Many thanks for the response.
John Cox
/simple-dmabuf-gbm in
>Weston.
>
>Hope this helps!
Very many thanks for the pointers - to a large extent my problem is that
I don't know what should work in order to build something around it and
then work out why it doesn't. I've got video decode down pat, but
modern display still eludes me - I grew up on STBs and the like where
you could just use the h/w directly, now its a lot more controlled.
Ta again
John Cox
tempted to just not
bother here and keep the old, more lose check. Especially given that
John has a patch ready that removes try_get_page entirely.
Yes. Andrew has accepted it into mmotm.
Ralph's patch here was written well before my cleanup that removed
try_grab_page() [1]. But now tha
o a hardware scheduler. It is behaviour
that should be implemented at the front end not the back end. If we
absolutely need to do this then we need to do it solely at the context
management level not at the back end submission level. And the solution
should work by default on any submission back
On 8/9/2021 23:36, Daniel Vetter wrote:
On Mon, Aug 09, 2021 at 04:12:52PM -0700, John Harrison wrote:
On 8/6/2021 12:46, Daniel Vetter wrote:
Seen this fly by and figured I dropped a few thoughts in here. At the
likely cost of looking a bit out of whack :-)
On Fri, Aug 6, 2021 at 8:01 PM
On 7/26/2021 20:17, Matthew Brost wrote:
Like in the case of several other selftests, generating lots of requests
in a loop takes a bit longer with GuC submission. Increase a timeout in
i915_gem_contexts selftest to take this into account.
Signed-off-by: Matthew Brost
Reviewed-by: John
ory in vidmem.
So I think we don't want to rule out that behavior, right? Or is the
thinking more like, "you're lucky that this old non-ODP setup works at
all, and we'll make it work by routing through host/cpu memory, but it
will be slow"?
thanks,
--
John Hubbard
NVIDIA
block migration from happening eg if the CPU touches it
later or something.
OK. I just want to avoid creating any API-level assumptions that dma_buf_pin()
necessarily implies or requires migrating to host memory.
thanks,
--
John Hubbard
NVIDIA
;t need to worry so much about
providing first-class support for non-ODP setups.
I've got to drag my brain into 2021+! :)
thanks,
--
John Hubbard
NVIDIA
...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/system_heap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 23a7e74ef966..f57a39ddd063 100644
--- a
for these magic
numbers. That seems like a very bad idea. They should be moved into a
helper function rather than repeated.
John.
if (!intel_uc_uses_guc_submission(>->uc))
@@ -476,12 +492,12 @@ static void guc_init_golden_context(struct intel_guc *guc)
unlock*" items to "mlock*", where applicable. good grief.
Although, it seems reasonable to tack such renaming patches onto the tail end
of this series. But whatever works.
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-dev
as there
is only one caller of try_to_munlock.
- Alistair
No objections here. :)
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 3/30/21 8:56 PM, John Hubbard wrote:
On 3/30/21 3:56 PM, Alistair Popple wrote:
...
+1 for renaming "munlock*" items to "mlock*", where applicable. good grief.
At least the situation was weird enough to prompt further investigation :)
Renaming to mlock* doesn&#
> Totally agreed that nothing generic can rely on pages being transported
> > via dma-buf, and memfd is there if you do want a suitable transport. The
> > one I don't know about is dma-buf heap, do both parties there consent to
> > transport pages via the dma-buf? i.e. do
On Thu, Jan 14, 2021 at 12:54 PM wrote:
>
> On 2021-01-13 18:28, John Stultz wrote:
> > On Wed, Jan 13, 2021 at 11:52 AM Veera Sundaram Sankaran
> > wrote:
> >>
> >> The explicit out-fences in crtc are signaled as part of vblank event,
> >> indi
ra Sundaram Sankaran
> ---
> drivers/dma-buf/dma-fence.c | 70
> -
> include/linux/dma-fence.h | 3 ++
> 2 files changed, 66 insertions(+), 7 deletions(-)
Thanks for respinning this!
Reviewed-by: John Stultz
-john
__
d more information to commit text
>
> Changes in v3:
> - use same backend helper function for variants of drm_send_event to
> avoid code duplications
>
> Changes in v4:
> - remove WARN_ON from drm_send_event_timestamp_locked
>
> Signed-off-by: Veera Sundaram Sankaran
saryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Suggested-by: Suren Baghdasaryan
Signed-off-by: John Stultz
---
drivers/dma
: John Stultz
---
drivers/dma-buf/dma-heap.c | 14 +-
drivers/dma-buf/heaps/cma_heap.c| 22 +++---
drivers/dma-buf/heaps/system_heap.c | 21 +++--
include/linux/dma-heap.h| 12 ++--
4 files changed, 33 insertions(+), 36
y
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Suggested-by: Suren Baghdasaryan
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c| 1 +
drivers/dma-buf/heaps/system_heap.c | 1 +
2 files changed, 2 inser
still think separate heap chardevs is
the way to go.
thanks
-john
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Bing Song
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c | 119
y
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: Bing Song
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John S
: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: Bing Song
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/dma-heap.c | 33 +
include/linux/dma-heap.h | 9
On Fri, Jan 22, 2021 at 2:21 PM Suren Baghdasaryan wrote:
> On Thu, Jan 21, 2021 at 11:56 PM Sumit Semwal wrote:
> > On Wed, 20 Jan 2021 at 02:15, John Stultz wrote:
> > >
> > > We shouldn't vunmap more then we vmap, but if we do, make
> > > sure we co
On Mon, Dec 21, 2020 at 2:09 PM Daniel Vetter wrote:
>
> On Fri, Dec 18, 2020 at 05:16:56PM -0800, John Stultz wrote:
> > On Fri, Dec 18, 2020 at 6:36 AM Daniel Vetter wrote:
> > > On Thu, Dec 17, 2020 at 11:06:11PM +, John Stultz wrote:
> > > > Reuse/abuse t
Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix sleep in atomic issue from using a mutex, by switching
: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix
Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Rework deferred-free api to use reason enum as
On Wed, Jan 27, 2021 at 12:21 PM Daniel Mentz wrote:
>
> On Fri, Jan 22, 2021 at 7:47 PM John Stultz wrote:
> > +static int system_heap_clear_pages(struct page **pages, int num, pgprot_t
> > pgprot)
> > +{
> > + void *addr = vmap(pages, num, VM_MAP, pgprot
Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix sleep in atomic issue from using a mutex, by switching
: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix
Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Rework deferred-free api to use reason enum as
ux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kselft...@vger.kernel.org
Fixes: a8779927fd86c ("kselftests: Add dma-heap test")
Signed-off-by: John Stultz
---
tools/testing/selftests/dmabuf-heaps/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Mentz
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: John Stultz
---
.../testing/selftests/dmabuf-heaps/dmabuf-heap.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selfte
...@vger.kernel.org
Signed-off-by: John Stultz
---
.../selftests/dmabuf-heaps/dmabuf-heap.c | 20 ---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
index
...@vger.kernel.org
Signed-off-by: John Stultz
---
.../selftests/dmabuf-heaps/dmabuf-heap.c | 44 +--
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
index
@lists.freedesktop.org
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: John Stultz
---
.../selftests/dmabuf-heaps/dmabuf-heap.c | 86 +++
1 file changed, 86 insertions(+)
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
dm_mr.close()
+
+
+def check_dmabuf_support(unit=0):
+"""
+Check if dma-buf allocation is supported by the system.
+Skip the test on failure.
+"""
+device_num = 128 + unit
+try:
+DmaBuf(1, unit=unit)
unit?? Th
Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix sleep in atomic issue from using a mutex, by switching
: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix
Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Rework deferred-free api to use reason enum as
/2018-October/127519.html
> (sorry, could not find lore links for these discussions)
>
> Suggested-by: Laura Abbott
> Signed-off-by: Suren Baghdasaryan
For consistency, do we need something similar for the cma heap as well?
thanks
-john
___
On Tue, Feb 2, 2021 at 6:04 AM Daniel Vetter wrote:
>
> On Fri, Jan 22, 2021 at 05:28:32PM -0800, John Stultz wrote:
> > On Mon, Dec 21, 2020 at 2:09 PM Daniel Vetter wrote:
> > >
> > > On Fri, Dec 18, 2020 at 05:16:56PM -0800, John Stultz wrote:
> > > &
ng some
Kconfig settings from that subsystem. Headers exist to make information
available to external code. Kconfig (particularly for a subsystem) exist
to configure that subsystem.
But my feeling on this may be misguided. Is it generally accepted in the
kernel tha
spective of
process can hang). That's no good.
We have moved from using gfx paths to using kfd paths as of the 20.45 release a
couple of months ago. Not sure if that applies to APU's yet but if not I would
expect it to just be a matter of time.
Thanks,
John
Original Message
Fro
about the future of pinning to vidmem,
for this? It would allow a huge group of older GPUs and NICs and such to
do p2p with this approach, and it seems like a natural next step, right?
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
way to use this solution here for peer-to-peer. So I'm glad to see that
so far you're not ruling out the pinning option.
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Obviously not worth spinning another version for that, as it is still readable
as-is. Just mentioning it for the sake of pointless perfectionism, and in case
someone ever wonders why it was missed during a review. :) Either way, feel free
to add:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NV
_pool to use it, and then adds the
dmabuf deferred freeing and adds support to the dmabuf system
heap to use both deferred freeing and the new drm_page_pool.
Input would be greatly appreciated. Testing as well, as I don't
have any development hardware that utilizes the ttm pool.
than
: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/gpu/drm/Kconfig | 4
Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/gpu/drm/ttm/ttm_pool.c | 37
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/gpu/drm/ttm/ttm_pool.c | 60 ++
1 file changed, 32 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/gpu/drm/Kconfig| 1 +
drivers/gpu/drm/ttm/ttm_pool.c | 199 +++--
include/drm/ttm/ttm_pool.h | 23 +---
3 fi
Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix sleep in atomic issue from using a
: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix
: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Rework deferred-free api to use
On Fri, Feb 5, 2021 at 12:28 AM Christian König
wrote:
> Am 05.02.21 um 09:06 schrieb John Stultz:
> > This refactors ttm_pool_free_page(), and by adding extra entries
> > to ttm_pool_page_dat, we then use it for all allocations, which
> > allows us to simplify the argument
in, but not a refcount
pin.)
It's a nice clean design point that we need to preserve, and fortunately it
doesn't conflict with anything I'm seeing here. But I want to say this out
loud because I see some doubt about it creeping into the discussion.
thanks,
--
John Hubbard
NVIDIA
On Fri, Feb 5, 2021 at 12:47 AM Christian König
wrote:
> Am 05.02.21 um 09:06 schrieb John Stultz:
> > diff --git a/drivers/gpu/drm/page_pool.c b/drivers/gpu/drm/page_pool.c
> > new file mode 100644
> > index ..2139f86e6ca7
> > --- /dev/null
> >
On Fri, Feb 5, 2021 at 2:36 AM Christian König wrote:
> Am 05.02.21 um 09:06 schrieb John Stultz:
> > Input would be greatly appreciated. Testing as well, as I don't
> > have any development hardware that utilizes the ttm pool.
>
> We can easily do the testing and the ge
1 - 100 of 3397 matches
Mail list logo
