On 17/02/2023 22:13, Bryan O'Donoghue wrote:
> On 17/02/2023 12:24, Krzysztof Kozlowski wrote:
>> First, it would be nice to know what was the intention of Bryan's commit?
>
> Sorry I've been grazing this thread but, not responding.
>
> - qcom,dsi-ctrl-6g-qcm2290
>
> is non-compliant with qcom,s
On 17.02.2023 22:07, Dmitry Baryshkov wrote:
> On 14/02/2023 19:31, Konrad Dybcio wrote:
>> Currently we only utilize the OPP table connected to the GPU for
>> getting (available) frequencies. We do however need to scale the
>> voltage rail(s) accordingly to ensure that we aren't trying to
>> ru
On 18.02.2023 11:14, Krzysztof Kozlowski wrote:
> On 17/02/2023 22:13, Bryan O'Donoghue wrote:
>> On 17/02/2023 12:24, Krzysztof Kozlowski wrote:
>>> First, it would be nice to know what was the intention of Bryan's commit?
>>
>> Sorry I've been grazing this thread but, not responding.
>>
>> - q
On 17/02/2023 23:21, Konrad Dybcio wrote:
On 17.02.2023 22:19, Dmitry Baryshkov wrote:
On 14/02/2023 19:31, Konrad Dybcio wrote:
A619_holi is a GMU-less variant of the already-supported A619 GPU.
It's present on at least SM4350 (holi) and SM6375 (blair). No mesa
changes are required. Add the
On 18/02/2023 12:23, Konrad Dybcio wrote:
>
>
> On 18.02.2023 11:14, Krzysztof Kozlowski wrote:
>> On 17/02/2023 22:13, Bryan O'Donoghue wrote:
>>> On 17/02/2023 12:24, Krzysztof Kozlowski wrote:
First, it would be nice to know what was the intention of Bryan's commit?
>>>
>>> Sorry I've bee
On 18/02/2023 13:04, Konrad Dybcio wrote:
On 17.02.2023 22:07, Dmitry Baryshkov wrote:
On 14/02/2023 19:31, Konrad Dybcio wrote:
Currently we only utilize the OPP table connected to the GPU for
getting (available) frequencies. We do however need to scale the
voltage rail(s) accordingly to ens
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 de
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-ar
From: Rob Clark
This series adds deadline awareness 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) To
From: Rob Clark
Propagate the deadline to all the fences in the chain.
Signed-off-by: Rob Clark
Reviewed-by: Christian König for this one.
---
drivers/dma-buf/dma-fence-chain.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/dma-buf/dma-fence-chain.c
b/drivers/dma-
From: Rob Clark
Add a way to set a deadline on remaining resv fences according to the
requested usage.
Signed-off-by: Rob Clark
---
drivers/dma-buf/dma-resv.c | 19 +++
include/linux/dma-resv.h | 2 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.
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 on the
fe
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 be
From: Rob Clark
Allow userspace to use the EPOLLPRI/POLLPRI flag to indicate an urgent
wait (as opposed to a "housekeeping" wait to know when to cleanup after
some work has completed). Usermode components of GPU driver stacks
often poll() on fence fd's to know when it is safe to do things like
f
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/drm_atomic_he
As the finished fence is the one that is exposed to userspace, and
therefore the one that other operations, like atomic update, would
block on, we need to propagate the deadline from from the finished
fence to the actual hw fence.
v2: Split into drm_sched_fence_set_parent() (ckoenig)
v3: Ensure a
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.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 4 +-
drivers/gpu/drm/msm/msm_fence.c | 74 ++
From: Rob Clark
Will be used in the next commit to set a deadline on fences that an
atomic update is waiting on.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_vblank.c | 32
include/drm/drm_vblank.h | 1 +
2 files changed, 33 insertions(+)
diff --git a
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
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-deadline
From: Rob Clark
Signed-off-by: Rob Clark
---
This should probably be re-written by someone who knows the i915
request/timeline stuff better, to deal with non-immediate deadlines.
But as-is I think this should be enough to handle the case where
we want syncobj waits to trigger boost.
drivers/g
21 matches
Mail list logo
