On Fri, Oct 01, 2021 at 02:52:41PM -0300, Jason Gunthorpe wrote:
> This addresses Cornelia's remark on the earlier patch that ccw has a
> confusing lifecycle. While it doesn't seem like the original attempt was
> functionally wrong, the result can be made better with a lot of further
> work.
>
> R
Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
"PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor
accidentally (?) set blocking=true.
This can cause upwards of 60-100ms of unneeded latency when exiting
self-refresh, which can cause very noticeable lag
From: Rob Clark
[ Upstream commit f6f59072e821901d96c791864a07d57d8ec8d312 ]
I've seen some crashes in our crash reporting that *look* like multiple
threads stomping on each other while communicating with GMU. So wrap
all those paths in a lock.
Signed-off-by: Rob Clark
Signed-off-by: Sasha Le
On Wed, Oct 20, 2021 at 04:17:28PM -0700, Brian Norris wrote:
> Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
> "PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor
> accidentally (?) set blocking=true.
IIRC this wasn't accidental.
The reason it becam
On Wed, Oct 20, 2021 at 5:40 PM Sean Paul wrote:
> On Wed, Oct 20, 2021 at 04:17:28PM -0700, Brian Norris wrote:
> > Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
> > "PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor
> > accidentally (?) set blockin
Hi all,
On Tue, 5 Oct 2021 10:23:23 +0200 Christian König
wrote:
>
> Am 05.10.21 um 09:59 schrieb Stephen Rothwell:
> >
> > After merging the drm-misc tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > include/linux/dma-buf.h:456: warning: Function parameter or member '
(Dropping Andrzej, because that address keeps bouncing. Does
MAINTAINERS and/or .mailmap need updating?)
Apologies for the double reply here, but I forgot to mention one last
thing for now:
On Wed, Oct 20, 2021 at 5:40 PM Sean Paul wrote:
>
> On Wed, Oct 20, 2021 at 04:17:28PM -0700, Brian Norri
This is latest iteration of GPU memory tracepoints [1].
In the past, there were questions about the "big picture" of memory
accounting [2], especially given related work on dma-buf heaps and DRM
cgroups [3]. Also, there was a desire for a non-driver specific solution.
The great news is the dma
- Add helper functions for above tracepoints in the drm_gem.{h,c}
files
- Given more tracepoints, a drm_trace.* file may be started
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_gem.c | 49 +++
include/drm/drm_gem.
The existing gpu_mem_total tracepoint [1] is not currently used by
any in-tree consumers, we should add some.
In addition, there's a desire to report imported memory via the
counters too [2].
To do this, we'll have to redefine the event to:
a) Change 'pid' to 'ctx_id'
The reason is DRM subsyst
Sometimes, an exported dma-buf is added to the import list.
That messes up with trace point accounting, so track real vs.
fake imports to correct this.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 5 -
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prim
- drm_gem_handle_create_tail(..) increases the per instance
memory counter.
- drm_gem_object_release_handle(..) decreases the per instance
memory counter.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_
- drm_gem_prime_fd_to_handle increases the per-instance imported
memory counter
- drm_gem_remove_prime_handles decreases the per-instance imported
memory counter on non-fake imports.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 3 +++
drivers/gpu/drm/drm_prime.c | 2 ++
- drm_gem_private_object_init(..) increases the total memory
counter.
* All GEM objects (whether allocated or imported) seem to begin
there.
* If there's a better place/method, please do let
me know.
- drm_gem_object_free(..) decreases the total memory counter.
Signed-off-by: Gurch
For struct drm_device, add:
- mem_total
- import_mem_total
For struct drm_file, add:
- mem_instance
- import_mem_instance
Signed-off-by: Gurchetan Singh
---
include/drm/drm_device.h | 16
include/drm/drm_file.h | 16
2 files changed, 32 insert
- drm_gem_prime_import_dev increases the per-device import memory
counter
* Most drivers use it.
* drivers that have a (*gem_prime_import) callback will need
additional changes, which can be done if everyone likes the
overall RFC.
- drm_prime_gem_destroy decreases the per-device im
On Wed, 20 Oct 2021 20:10:23 -0700
Gurchetan Singh wrote:
> - drm_gem_private_object_init(..) increases the total memory
> counter.
>
> * All GEM objects (whether allocated or imported) seem to begin
> there.
> * If there's a better place/method, please do let
> me know.
>
> - drm
On Wed, 20 Oct 2021 20:10:24 -0700
Gurchetan Singh wrote:
> @@ -305,6 +306,7 @@ drm_gem_object_release_handle(int id, void *ptr, void
> *data)
> drm_gem_remove_prime_handles(obj, file_priv);
> drm_vma_node_revoke(&obj->vma_node, file_priv);
>
> + drm_gem_trace_gpu_mem_instance(
DPCD 248h name was changed from “PHY_TEST_PATTERN” in DP 1.4 to
“LINK_QUAL_PATTERN_SELECT” in DP 2.0.
Also, DPCD 248h [6:0] is the same as DPCDs 10Bh/10Ch/10Dh/10Eh [6:0]. So
removed the repeated definition of PHY patterns.
Reference: “DPCD 248h/10Bh/10Ch/10Dh/10Eh Name/Description Consistency”
This series updates DPCD 248h register name and PHY test patterns names to
follow DP 2.0 Specs.
Also updates the DP PHY CTS codes of the affected drivers (i915, amd, msm)
No functional changes expected.
Reference: “DPCD 248h/10Bh/10Ch/10Dh/10Eh Name/Description Consistency”
https://groups.vesa.o
Use the new definition of DPCD 248h (DP_LINK_QUAL_PATTERN_SELECT)
No functional changes.
Cc: Harry Wentland
Cc: Alex Deucher
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
Update selected phy test pattern names to use the new names/definitions of DPCD
248h in DP2.0/drm_dp_helpers.h
No functional changes
Cc: Manasi Navare
CC: Jani Nikula
Cc: Imre Deak
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
1 file changed
Use DP 2.0 DPCD 248h new name (LINK_QUAL_PATTERN_SELECT) and rename selected
phy test patterns to LINK_QUAL_PATTERN_*
Note: TPS4 LT pattern is CP2520 Pattern 3 (refer to DP2.0 spaces Table 3-11,
DPCD 00248h
LINK_QUAL_PATTERN_SELECT, and DP PHY 1.4 CTS - Appendix A - Compliance EYE
Pattern(CP252
On Wed, 2021-10-20 at 13:34 -0700, John Harrison wrote:
> On 10/11/2021 10:57, Matthew Brost wrote:
> > perf_parallel_engines is micro benchmark to test i915 request
> > scheduling. The test creates a thread per physical engine and
> > submits
> > NOP requests and waits the requests to complete in
On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:
> Use __release_guc_id (lock held) rather than release_guc_id (acquires
> lock), add lockdep annotations.
>
> 213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr
> [ 213.283459]
> [ 213
On Mon, 2021-10-11 at 12:40 -0700, Matthew Brost wrote:
> The hangcheck selftest blows on DG1 CI and aborts the BAT run.
> Investigation is underway to root cause the failure but in the
> meantime
> disable to this test on DG1 to unblock CI.
>
> Signed-off-by: Matthew Brost
Reviewed-by: Thomas H
Hi, Matthew,
On Mon, 2021-10-11 at 16:47 -0700, Matthew Brost wrote:
> The hangcheck selftest blocks per engine resets by setting magic bits
> in
> the reset flags. This is incorrect for GuC submission because if the
> GuC
> fails to reset an engine we would like to do a full GT reset. Do no
> set
Am 20.10.21 um 21:32 schrieb Andrey Grodzovsky:
On 2021-10-04 4:14 a.m., Christian König wrote:
The problem is a bit different.
The callback is on the dependent fence, while we need to signal the
scheduler fence.
Daniel is right that this needs an irq_work struct to handle this
properly
101 - 128 of 128 matches
Mail list logo
