From: Rob Clark
In the process of adding lockdep annotation for drm GPU scheduler's
job_run() to detect potential deadlock against shrinker/reclaim, I hit
this lockdep splat:
==
WARNING: possible circular locking dependency detected
From: Rob Clark
For cases where icc_bw_set() can be called in callbaths that could
deadlock against shrinker/reclaim, such as runpm resume, we need to
decouple the icc locking. Introduce a new icc_bw_lock for cases where
we need to serialize bw aggregation and update to decouple that from
paths
From: Rob Clark
Preparing for better lockdep annotations for things that happen in runpm
suspend/resume path vs shrinker/reclaim in the following patches, we
need to avoid allocations that can trigger reclaim in the icc_set_bw()
path. In the RPMh case, rpmh_write_batch() already uses GFP_ATOMIC
From: Rob Clark
Similar to the previous patch, move the allocation out from under
dev_pm_qos_mtx, by speculatively doing the allocation and handle
any race after acquiring dev_pm_qos_mtx by freeing the redundant
allocation.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 12
From: Rob Clark
This will make it easier to catch places doing allocations that can
trigger reclaim under devfreq->lock.
Because devfreq->lock is held over various devfreq_dev_profile
callbacks, there might be some fallout if those callbacks do allocations
that can trigger reclaim, bu
From: Rob Clark
In the process of adding lockdep annotation for GPU job_run() path to
catch potential deadlocks against the shrinker/reclaim path, I turned
up this lockdep splat:
==
WARNING: possible circular locking dependency detected
From: Rob Clark
These allocations are only done the first (successful) time through
hw_init() so they won't actually happen in the job_run() path. But
lockdep doesn't know this. So dis-entangle them from the hw_init()
path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c
From: Rob Clark
Move the one-time RPMh setup to a6xx_gmu_init(). To get rid of the hack
for one-time init vs start, add in an extra a6xx_rpmh_stop() at the end
of the init sequence.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 18 --
1 file changed, 8
From: Rob Clark
It is already a no-op, since we've already loaded the fw from
adreno_load_gpu(), so drop the redundant call.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm
From: Rob Clark
Since the LRU lock is already acquired when moving an obj between LRUs,
we can use it to protect pin_count and madv, without any significant
change in locking (ie. it just expands the scope of the lock by a hand-
ful of instructions). This prepares the way to decrement
From: Rob Clark
Now that everything that controls which LRU an obj lives in *except* the
backing pages is protected by the LRU lock, add a special path to unpin
in the job_run() path, we we are assured that we already have backing
pages and will not be racing against eviction (because the GEM
From: Rob Clark
Needed to idr_preload() which returns with preemption disabled.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 6 ++
drivers/gpu/drm/msm/msm_gem_submit.c | 10 +-
drivers/gpu/drm/msm/msm_gpu.h | 2 +-
drivers/gpu/drm/msm
From: Rob Clark
Avoid allocation under idr_lock, to prevent deadlock against the
job_free() path (which runs on same thread as job_run(), which makes
it also part of the fence-signaling path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 8 ++--
1 file changed, 6
From: Rob Clark
Export the locked version or lru's move_tail().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 11 ++-
include/drm/drm_gem.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index
From: Rob Clark
Just code-motion.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 46 +--
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 009a34b3a49b..c97dddf3e2f2
From: Rob Clark
Stop open coding VMA construction, which will be needed in the next
commit. And since the VMA already has a ptr to the adress space, stop
passing that around everywhere. (Also, an aspace always has an mmu so
we can drop a couple pointless NULL checks.)
Signed-off-by: Rob Clark
From: Rob Clark
The flags are only accessed (1) when submit is constructed, before
enqueuing to gpu sched (ie. when still visible to only the task calling
the submit ioctl), (2) here, where we own a reference to the submit and
are serialized on the gpu sched thread, and (3) after the submit
From: Rob Clark
vmap'ing is just pinning in disguise. So treat it as such and simplify
the LRU tracking.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers
From: Rob Clark
We need to use the inuse count to track that a BO is pinned until
we have the hw_fence. But we want to remove the obj lock from the
job_run() path as this could deadlock against reclaim/shrinker
(because it is blocking the hw_fence from eventually being signaled).
So split
From: Rob Clark
Avoid allocating memory in job_run() by pre-allocating the hw_fence.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.c | 12 +---
drivers/gpu/drm/msm/msm_fence.h | 3 ++-
drivers/gpu/drm/msm/msm_gem_submit.c | 7 +++
drivers/gpu/drm/msm
From: Rob Clark
Inspired by
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
it seemed like a good idea to get rid of memory allocation in job_run()
fence signaling path, and use lockdep annotations to yell at us about
anything that could deadlock against
On Fri, Mar 17, 2023 at 12:08 PM Faith Ekstrand wrote:
>
>
> On Wed, Mar 8, 2023 at 9:54 AM Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> Add a new flag to let userspace provide a deadline as a hint for syncobj
>> and timeline waits. This gives a hint
On Fri, Mar 17, 2023 at 12:08 PM Faith Ekstrand wrote:
>
>
> On Wed, Mar 8, 2023 at 9:54 AM Rob Clark wrote:
>>
>> From: Rob Clark
>>
>> Add a new flag to let userspace provide a deadline as a hint for syncobj
>> and timeline waits. This gives a hint
On Fri, Mar 17, 2023 at 3:23 AM Jonas Ådahl wrote:
>
> On Thu, Mar 16, 2023 at 09:28:55AM -0700, Rob Clark wrote:
> > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote:
> > >
> > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > > > O
On Thu, Mar 16, 2023 at 3:22 PM Sebastian Wick
wrote:
>
> On Thu, Mar 16, 2023 at 5:29 PM Rob Clark wrote:
> >
> > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote:
> > >
> > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > > > On
On Wed, Mar 8, 2023 at 7:53 AM Rob Clark wrote:
>
> From: Rob Clark
>
> This series adds a deadline hint to fences, so realtime deadlines
> such as vblank can be communicated to the fence signaller for power/
> frequency management decisions.
>
> This is partially inspi
On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote:
>
> On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote:
> > >
> > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote:
> > > > O
Hi Dave,
As discussed, an early msm-next pull req for v6.4 with PSR and related
core helper bits.
The following changes since commit dbd7a2a941b8cbf9e5f79a777ed9fe0090eebb61:
PM / devfreq: Fix build issues with devfreq disabled (2023-01-30
07:37:40 -0800)
are available in the Git repository
On Wed, Mar 15, 2023 at 1:35 PM Dave Airlie wrote:
>
> Hey moduly/firmware people,
>
> We are facing a problem in the future of NVIDIA providing giant
> firmwares for their devices that are version locked with unstable
> APIs. Even if they weren't version locked we'd likely have to support
>
On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote:
>
> On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote:
> > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl wrote:
> > >
> > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote:
> > > >
On Mon, Mar 13, 2023 at 9:15 AM Christian König
wrote:
>
> Am 13.03.23 um 15:45 schrieb Rob Clark:
> > On Mon, Mar 13, 2023 at 12:19 AM Christian König
> > wrote:
> >> Am 11.03.23 um 18:35 schrieb Rob Clark:
> >>> From: Rob Clark
> >>>
>
On Mon, Mar 13, 2023 at 5:31 AM Rafael J. Wysocki wrote:
>
> On Sun, Mar 12, 2023 at 9:42 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Annotate dev_pm_qos_mtx to teach lockdep to scream about allocations
> > that could trigger reclaim under dev_p
On Mon, Mar 13, 2023 at 12:19 AM Christian König
wrote:
>
> Am 11.03.23 um 18:35 schrieb Rob Clark:
> > From: Rob Clark
> >
> > Avoid allocating memory in job_run() by embedding the fence in the
> > submit object. Since msm gpu fences are always 1:1 with msm_
From: Rob Clark
Preparing for better lockdep annotations for things that happen in runpm
suspend/resume path vs shrinker/reclaim in the following patches, we
need to avoid allocations that can trigger reclaim in the icc_set_bw()
path. In the RPMh case, rpmh_write_batch() already uses GFP_ATOMIC
From: Rob Clark
In the process of adding lockdep annotation for drm GPU scheduler's
job_run() to detect potential deadlock against shrinker/reclaim, I hit
this lockdep splat:
==
WARNING: possible circular locking dependency detected
From: Rob Clark
For cases where icc_bw_set() can be called in callbaths that could
deadlock against shrinker/reclaim, such as runpm resume, we need to
decouple the icc locking. Introduce a new icc_bw_lock for cases where
we need to serialize bw aggregation and update to decouple that from
paths
From: Rob Clark
Teach lockdep that icc_bw_lock is needed in code paths that could
deadlock if they trigger reclaim.
Signed-off-by: Rob Clark
---
drivers/interconnect/core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/core.c b/drivers
From: Rob Clark
Annotate dev_pm_qos_mtx to teach lockdep to scream about allocations
that could trigger reclaim under dev_pm_qos_mtx.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/base/power/qos.c b/drivers/base
From: Rob Clark
Similar to the previous patch, move the allocation out from under
dev_pm_qos_mtx, by speculatively doing the allocation and handle
any race after acquiring dev_pm_qos_mtx by freeing the redundant
allocation.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 12
From: Rob Clark
This will make it easier to catch places doing allocations that can
trigger reclaim under devfreq->lock.
Because devfreq->lock is held over various devfreq_dev_profile
callbacks, there might be some fallout if those callbacks do allocations
that can trigger reclaim, bu
From: Rob Clark
Move the one-time RPMh setup to a6xx_gmu_init(). To get rid of the hack
for one-time init vs start, add in an extra a6xx_rpmh_stop() at the end
of the init sequence.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 18 --
1 file changed, 8
From: Rob Clark
In the process of adding lockdep annotation for GPU job_run() path to
catch potential deadlocks against the shrinker/reclaim path, I turned
up this lockdep splat:
==
WARNING: possible circular locking dependency detected
From: Rob Clark
These allocations are only done the first (successful) time through
hw_init() so they won't actually happen in the job_run() path. But
lockdep doesn't know this. So dis-entangle them from the hw_init()
path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c
From: Rob Clark
It is already a no-op, since we've already loaded the fw from
adreno_load_gpu(), so drop the redundant call.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm
From: Rob Clark
Avoid allocating memory in job_run() by embedding the fence in the
submit object. Since msm gpu fences are always 1:1 with msm_gem_submit
we can just use the fence's refcnt to track the submit. And since we
can get the fence ctx from the submit we can just drop the msm_fence
From: Rob Clark
Add a way to initialize a fence without touching the refcount. This is
useful, for example, if the fence is embedded in a drm_sched_job. In
this case the refcount will be initialized before the job is queued.
But the seqno of the hw_fence is not known until job_run().
Signed
From: Rob Clark
Inspired by
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
it seemed like a good idea to get rid of memory allocation in job_run()
and use lockdep annotations to yell at us about anything that could
deadlock against shrinker/reclaim. Anything
From: Rob Clark
Add a way to initialize a fence without touching the refcount. This is
useful, for example, if the fence is embedded in a drm_sched_job. In
this case the refcount will be initialized before the job is queued.
But the seqno of the hw_fence is not known until job_run().
Signed
From: Rob Clark
Inspired by
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
it seemed like a good idea to get rid of memory allocation in job_run()
by embedding the hw dma_fence in the job/submit struct.
Applies on top of https://patchwork.freedesktop.org
From: Rob Clark
Avoid allocating memory in job_run() by embedding the fence in the
submit object. Since msm gpu fences are always 1:1 with msm_gem_submit
we can just use the fence's refcnt to track the submit. And since we
can get the fence ctx from the submit we can just drop the msm_fence
On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl wrote:
>
> On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > Add a way to hint to the fence signaler of an upcoming deadline, such as
> > vblank, which the fence waiter would prefe
drm/msm: DEVFREQ_GOV_SIMPLE_ONDEMAND is no longer needed
Rob Clark (1):
drm/msm: Fix potential invalid ptr free
Thomas Zimmermann (1):
drm/msm: Fix possible uninitialized access in fbdev
drivers/gpu/drm/msm/Kconfig| 1 -
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +-
drive
On Wed, Mar 8, 2023 at 1:23 PM Ville Syrjälä
wrote:
>
> On Wed, Mar 08, 2023 at 12:02:42PM -0800, Abhinav Kumar wrote:
> > For DRM property blobs created by user mode using
> > drm_property_create_blob(), if the blob value needs to be updated the
> > only way is to destroy the previous blob and
From: Rob Clark
I expect this patch to be replaced by someone who knows i915 better.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_request.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915
From: Rob Clark
Drop our custom thing and switch to drm_crtc_next_vblank_start() for
calculating the time of the start of the next vblank period.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 ---
drivers/gpu/drm/msm/msm_atomic.c| 8
From: Rob Clark
Will be used in the next commit to set a deadline on fences that an
atomic update is waiting on.
v2: Calculate time at *start* of vblank period, not end
v3: Fix kbuild complaints
Signed-off-by: Rob Clark
Reviewed-by: Mario Kleiner
---
drivers/gpu/drm/drm_vblank.c | 53
From: Rob Clark
Add a way for various userspace waits to signal urgency.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 12
drivers/gpu/drm/msm/msm_gem.c | 5 +
include/uapi/drm/msm_drm.h| 14 --
3 files changed, 25 insertions(+), 6 deletions
a thread calling drm_sched_fence_set_deadline_finished() sees
fence->parent set before drm_sched_fence_set_parent() does this
test_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT).
Signed-off-by: Rob Clark
Acked-by: Luben Tuikov
---
drivers/gpu/drm/scheduler/sched_fence.c |
From: Rob Clark
Track the nearest deadline on a fence timeline and set a timer to expire
shortly before to trigger boost if the fence has not yet been signaled.
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.c | 74 +
drivers/gpu/drm/msm
From: Rob Clark
For an atomic commit updating a single CRTC (ie. a pageflip) calculate
the next vblank time, and inform the fence(s) of that deadline.
v2: Comment typo fix (danvet)
v3: If there are multiple CRTCs, consider the time of the soonest vblank
Signed-off-by: Rob Clark
Reviewed
From: Rob Clark
Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits. This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can addjust GPU frequency accordingly. An immediate deadline can
From: Rob Clark
This consists of simply storing the most recent deadline, and adding an
ioctl to retrieve the deadline. This can be used in conjunction with
the SET_DEADLINE ioctl on a fence fd for testing. Ie. create various
sw_sync fences, merge them into a fence-array, set deadline
From: Rob Clark
We had all of the internal driver APIs, but not the all important
userspace uABI, in the dma-buf doc. Fix that. And re-arrange the
comments slightly as otherwise the comments for the ioctl nr defines
would not show up.
v2: Fix docs build warning coming from newly including
From: Rob Clark
The initial purpose is for igt tests, but this would also be useful for
compositors that wait until close to vblank deadline to make decisions
about which frame to show.
The igt tests can be found at:
https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence
From: Rob Clark
Add a way to set a deadline on remaining resv fences according to the
requested usage.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/dma-buf/dma-resv.c | 22 ++
include/linux/dma-resv.h | 2 ++
2 files changed, 24 insertions(+)
diff
From: Rob Clark
Propagate the deadline to all the fences in the chain.
v2: Use dma_fence_chain_contained [Tvrtko]
Signed-off-by: Rob Clark
Reviewed-by: Christian König for this one.
---
drivers/dma-buf/dma-fence-chain.c | 12
1 file changed, 12 insertions(+)
diff --git
From: Rob Clark
Propagate the deadline to all the fences in the array.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence
From: Rob Clark
Add a way to hint to the fence signaler of an upcoming deadline, such as
vblank, which the fence waiter would prefer not to miss. This is to aid
the fence signaler in making power management decisions, like boosting
frequency as the deadline approaches and awareness of missing
From: Rob Clark
This series adds a deadline hint to fences, so realtime deadlines
such as vblank can be communicated to the fence signaller for power/
frequency management decisions.
This is partially inspired by a trick i915 does, but implemented
via dma-fence for a couple of reasons:
1
t; (QCOM_COMMAND_DB [=y] || QCOM_COMMAND_DB [=y]=n)
> >
> > Fixes: 6563f60f14cb ("drm/msm/gpu: Add devfreq tuning debugfs")
> > Signed-off-by: Randy Dunlap
> > Reported-by: kernel test robot
> > Link: lore.kernel.org/r/202303071922.wjqdwqpe-...@intel.com
&
On Sat, Mar 4, 2023 at 3:27 PM Abhinav Kumar wrote:
>
> Update the URI for MSM DRM bugs for users to be able
> to file bugs at a centralized location.
>
> Signed-off-by: Abhinav Kumar
Acked-by: Rob Clark
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
On Fri, Mar 3, 2023 at 2:10 AM Dmitry Baryshkov
wrote:
>
> On 03/03/2023 01:53, Rob Clark wrote:
> > From: Rob Clark
> >
> > Track the nearest deadline on a fence timeline and set a timer to expire
> > shortly before to trigger boost if the fence has not yet bee
On Fri, Mar 3, 2023 at 7:12 AM Ville Syrjälä
wrote:
>
> On Thu, Mar 02, 2023 at 03:53:33PM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > For an atomic commit updating a single CRTC (ie. a pageflip) calculate
> > the next vblank time, and inform the fence(s
On Fri, Mar 3, 2023 at 7:20 AM Ville Syrjälä
wrote:
>
> On Fri, Mar 03, 2023 at 05:00:03PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 03, 2023 at 06:48:43AM -0800, Rob Clark wrote:
> > > On Fri, Mar 3, 2023 at 1:58 AM Tvrtko Ursulin
> > > wrote:
> > >
On Fri, Mar 3, 2023 at 7:08 AM Tvrtko Ursulin
wrote:
>
>
> On 03/03/2023 14:48, Rob Clark wrote:
> > On Fri, Mar 3, 2023 at 1:58 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 03/03/2023 03:21, Rodrigo Vivi wrote:
> >>> On Thu, Mar 02,
On Thu, Mar 2, 2023 at 7:21 PM Rodrigo Vivi wrote:
>
> On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
>
> missing some wording here...
the wording should be "Pls replace this patch, kthx" ;-)
>
> >
On Fri, Mar 3, 2023 at 1:58 AM Tvrtko Ursulin
wrote:
>
>
> On 03/03/2023 03:21, Rodrigo Vivi wrote:
> > On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >
> > missing some wording here...
> >
From: Rob Clark
Track the nearest deadline on a fence timeline and set a timer to expire
shortly before to trigger boost if the fence has not yet been signaled.
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.c | 74 +
drivers/gpu/drm/msm
From: Rob Clark
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_request.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043b..44491e7e214c 100644
From: Rob Clark
Drop our custom thing and switch to drm_crtc_next_vblank_start() for
calculating the time of the start of the next vblank period.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 ---
drivers/gpu/drm/msm/msm_atomic.c| 8
From: Rob Clark
Add a way for various userspace waits to signal urgency.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 12
drivers/gpu/drm/msm/msm_gem.c | 5 +
include/uapi/drm/msm_drm.h| 14 --
3 files changed, 25 insertions(+), 6 deletions
From: Rob Clark
Will be used in the next commit to set a deadline on fences that an
atomic update is waiting on.
v2: Calculate time at *start* of vblank period, not end
v3: Fix kbuild complaints
Signed-off-by: Rob Clark
Reviewed-by: Mario Kleiner
---
drivers/gpu/drm/drm_vblank.c | 53
From: Rob Clark
For an atomic commit updating a single CRTC (ie. a pageflip) calculate
the next vblank time, and inform the fence(s) of that deadline.
v2: Comment typo fix (danvet)
Signed-off-by: Rob Clark
Reviewed-by: Daniel Vetter
Signed-off-by: Rob Clark
---
drivers/gpu/drm
From: Rob Clark
Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits. This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can addjust GPU frequency accordingly. An immediate deadline can
a thread calling drm_sched_fence_set_deadline_finished() sees
fence->parent set before drm_sched_fence_set_parent() does this
test_bit(DMA_FENCE_FLAG_HAS_DEADLINE_BIT).
Signed-off-by: Rob Clark
Acked-by: Luben Tuikov
---
drivers/gpu/drm/scheduler/sched_fence.c |
From: Rob Clark
This consists of simply storing the most recent deadline, and adding an
ioctl to retrieve the deadline. This can be used in conjunction with
the SET_DEADLINE ioctl on a fence fd for testing. Ie. create various
sw_sync fences, merge them into a fence-array, set deadline
From: Rob Clark
The initial purpose is for igt tests, but this would also be useful for
compositors that wait until close to vblank deadline to make decisions
about which frame to show.
The igt tests can be found at:
https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence
From: Rob Clark
We had all of the internal driver APIs, but not the all important
userspace uABI, in the dma-buf doc. Fix that. And re-arrange the
comments slightly as otherwise the comments for the ioctl nr defines
would not show up.
v2: Fix docs build warning coming from newly including
From: Rob Clark
Add a way to set a deadline on remaining resv fences according to the
requested usage.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/dma-buf/dma-resv.c | 22 ++
include/linux/dma-resv.h | 2 ++
2 files changed, 24 insertions(+)
diff
From: Rob Clark
Propagate the deadline to all the fences in the chain.
v2: Use dma_fence_chain_contained [Tvrtko]
Signed-off-by: Rob Clark
Reviewed-by: Christian König for this one.
---
drivers/dma-buf/dma-fence-chain.c | 12
1 file changed, 12 insertions(+)
diff --git
From: Rob Clark
Propagate the deadline to all the fences in the array.
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence
From: Rob Clark
Add a way to hint to the fence signaler of an upcoming deadline, such as
vblank, which the fence waiter would prefer not to miss. This is to aid
the fence signaler in making power management decisions, like boosting
frequency as the deadline approaches and awareness of missing
From: Rob Clark
This series adds a deadline hint to fences, so realtime deadlines
such as vblank can be communicated to the fence signaller for power/
frequency management decisions.
This is partially inspired by a trick i915 does, but implemented
via dma-fence for a couple of reasons:
1
From: Rob Clark
Add a build option to disable modesetting support. This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.
As the modesetting ioctls are a big surface area
On Wed, Mar 1, 2023 at 11:25 PM Gerd Hoffmann wrote:
>
> On Thu, Mar 02, 2023 at 12:39:33AM +0300, Dmitry Osipenko wrote:
> > On 3/1/23 21:54, Rob Clark wrote:
> > > /* virtgpu_display.c */
> > > +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS)
> > > int virtio_gp
From: Rob Clark
Add a build option to disable modesetting support. This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.
As the modesetting ioctls are a big surface area
On Wed, Mar 1, 2023 at 7:31 AM Sebastian Wick wrote:
>
> On Tue, Feb 28, 2023 at 11:52 PM Rob Clark wrote:
> >
> > On Tue, Feb 28, 2023 at 6:30 AM Sebastian Wick
> > wrote:
> > >
> > > On Tue, Feb 28, 2023 at 12:48 AM Rob Clark wrote:
> > >
From: Rob Clark
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_request.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043b..44491e7e214c 100644
From: Rob Clark
Drop our custom thing and switch to drm_crtc_next_vblank_start() for
calculating the time of the start of the next vblank period.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 ---
drivers/gpu/drm/msm/msm_atomic.c| 8
From: Rob Clark
Add a way for various userspace waits to signal urgency.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 12
drivers/gpu/drm/msm/msm_gem.c | 5 +
include/uapi/drm/msm_drm.h| 14 --
3 files changed, 25 insertions(+), 6 deletions
501 - 600 of 5759 matches
Mail list logo
