With the dsc config being readout and filled in crtc_state add
macros and use them to compare current and previous PPS param in
DSC.
--v2
-Remove version check [Jani]
-Remove dupe macro for dsc pipe compare and use the existing ones
[Jani]
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/d
We have setup both the read and write functions so we can
move ahead and fill in all the readout state from PPS register
into the crtc_state so we can send it for comparision.
--v2
-Shorten comment to just PPSX rather than having the whole
"Readout PPSX register" [Jani]
-Remove pps_temp reinitiali
In intel_vdsc_get_config we only read the primary dsc engine register
and not take into account if the other dsc engine is in use and if
both registers have the same value or not this patche fixes that by
adding a check.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_vdsc.c
Now that we have a function that reads any PPS register based
on intel_dsc_pps enum provided lets create a function that can
write on any PPS.
--v2
-Changes need as PPS enum was dropped
-Remove duplicated code in intel_dsc_write_pps_reg [Jani]
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i9
Add function to read any PPS register based on the
intel_dsc_pps enum provided. Add a function which will call the
new pps read function and place it in crtc state. Only PPS0 and
PPS1 are readout the rest of the registers will be read in upcoming
patches.
--v2
-Changes in read function as PPS enum
This patch refactors dsc register related macros that prepares
the values to be written in the register. The current bit shifting
looks bad and going forward will not serve our purpose to readout
dsc register field values the change was suggested by Jani Nikula.
Cc: Jani Nikula
Signed-off-by: Sur
Up until now we only verified one or two of the dsc pps
params like bits_per_component and bits_per_pixel this
patch series aim to readout almost all PPS param and get
them compared.
Along with that some work on making a common function to
read and write PPS param regiters is also done.
--v2
-Remo
== Series Details ==
Series: drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests
(rev5)
URL : https://patchwork.freedesktop.org/series/117713/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13379_full -> Patchwork_117713v5_full
=
== Series Details ==
Series: drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests
(rev5)
URL : https://patchwork.freedesktop.org/series/117713/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13379 -> Patchwork_117713v5
===
== Series Details ==
Series: drm/i915: Introduce Wa_14011274333
URL : https://patchwork.freedesktop.org/series/120644/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC [M] drivers/gpu/drm/i915/gt/intel_rc6.o
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
between commit:
570b295248b0 ("drm/amdgpu: fix number of fence calculations")
from Linus' tree and commit:
ca6c1e210aa7 ("drm/amdgpu: use the new drm_exec object for CS v3")
Wa_14011274333 applies to RKL, ADL-S, ADL-P and TGL. ALlocate buffer
pinned to GGTT and add WA to restore impacted registers.
v2: use correct lineage number, more generically apply workarounds for
all registers impacted, move workaround to gt/intel_workarounds.c
(MattR)
Based off patch by Tilak T
Hi Carlos,
Em 27/06/2023 15:22, Carlos Eduardo Gallo Filho escreveu:
[...]
So, replace each drm_framebuffer_plane_{width,height} and
fb_plane_{width,height} call to drm_format_info_plane_{width,height}
and remove them.
I see that with this replace, there's a small code change from
r
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.
That said, all subsytems th
Hi Nirmoy,
> > @@ -301,11 +336,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32
> > mode)
> > cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
> > - if (!HAS_FLAT_CCS(rq->engine->i915)) {
> > - /* hsdes: 1809175790 */
>
> We shoul
On 7/12/2023 09:27, Andrzej Hajda wrote:
On 12.07.2023 14:35, Tvrtko Ursulin wrote:
On 12/07/2023 13:18, Andrzej Hajda wrote:
On 11.07.2023 17:27, Tvrtko Ursulin wrote:
On 11/07/2023 14:58, Andrzej Hajda wrote:
On 11.07.2023 13:34, Andi Shyti wrote:
Hi Andrzej,
drivers/gpu/drm/i915/gt/uc/i
On Wed, 2023-07-12 at 10:19 +0100, Tvrtko Ursulin wrote:
> On 11/07/2023 23:02, Alan Previn wrote:
> > On MTL, if the GSC Proxy init flows haven't completed, submissions to the
> > GSC engine will fail. Those init flows are dependent on the mei's
> > gsc_proxy component that is loaded in parallel w
On Fri, 2023-07-07 at 23:43 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/pxp/mtl: Update gsc-heci cmd size and timeout
> URL:https://patchwork.freedesktop.org/series/120360/
> State: failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120360v1/index.ht
I Like the acronym replacement approach - despite making the macro names
longer, it is consistent with how platform is referred everywhere in the driver.
For that,
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Monday, July 10, 2023 6:44 AM
> T
On 7/12/2023 3:03 AM, Andrzej Hajda wrote:
On 11.07.2023 22:31, Daniele Ceraolo Spurio wrote:
Due to a change in the auth flow on MTL, GuC 70.7.0 and newer will only
be able to authenticate HuC 8.5.1 and newer. The plan is to update the 2
binaries sinchronously in linux-firmware so that the f
On 12.07.2023 14:35, Tvrtko Ursulin wrote:
On 12/07/2023 13:18, Andrzej Hajda wrote:
On 11.07.2023 17:27, Tvrtko Ursulin wrote:
On 11/07/2023 14:58, Andrzej Hajda wrote:
On 11.07.2023 13:34, Andi Shyti wrote:
Hi Andrzej,
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
+++
-Original Message-
From: Nirmoy Das
Sent: Wednesday, July 12, 2023 7:18 AM
To: Andi Shyti ; Cavitt, Jonathan
Cc: Intel GFX ; Roper, Matthew D
; Chris Wilson ; Mika
Kuoppala
Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gt: Ensure memory quiesced
before invalidation
>
>Hi Andi and
== Series Details ==
Series: DRM cgroup controller with scheduling control and memory stats
URL : https://patchwork.freedesktop.org/series/120604/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC [M] drivers
On 6/27/2023 11:43 AM, Andi Shyti wrote:
Perform some refactoring with the purpose of keeping in one
single place all the operations around the aux table
invalidation.
With this refactoring add more engines where the invalidation
should be performed.
Fixes: 972282c4cf24 ("drm/i915/gen12: Add
On 6/27/2023 11:43 AM, Andi Shyti wrote:
From: Jonathan Cavitt
For platforms that use Aux CCS, wait for aux invalidation to
complete by checking the aux invalidation register bit is
cleared.
Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonat
Hi Andi and Jonathan,
On 6/27/2023 11:43 AM, Andi Shyti wrote:
From: Jonathan Cavitt
All memory traffic must be quiesced before requesting
an aux invalidation on platforms that use Aux CCS.
Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")
Signed-off-by: Jonatha
On 6/27/2023 11:43 AM, Andi Shyti wrote:
Fix the 'NV' definition postfix that is supposed to be INV.
Take the chance to also order properly the registers based on
their address and call the GEN12_GFX_CCS_AUX_INV address as
GEN12_CCS_AUX_INV like all the other similar registers.
Remove also VD
On Mon, Jul 10, 2023 at 07:31:22PM -0700, Yi Liu wrote:
> This can be used to differentiate whether to report group_id or devid in
> the revised VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl. At this moment, no
> cdev path yet, so the vfio_device_cdev_opened() helper always returns false.
>
> Reviewed-
On 7/11/2023 5:59 PM, Tvrtko Ursulin wrote:
On 10/07/2023 10:00, Nirmoy Das wrote:
Hi Tvrkto,
On 7/6/2023 3:43 PM, Tvrtko Ursulin wrote:
On 06/07/2023 14:35, Nirmoy Das wrote:
On 7/6/2023 3:32 PM, Tvrtko Ursulin wrote:
On 30/06/2023 18:01, Nirmoy Das wrote:
Use smem on MTL due to a HW
On 12/07/2023 13:18, Andrzej Hajda wrote:
On 11.07.2023 17:27, Tvrtko Ursulin wrote:
On 11/07/2023 14:58, Andrzej Hajda wrote:
On 11.07.2023 13:34, Andi Shyti wrote:
Hi Andrzej,
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
+++
1 file changed, 11 inse
On 11.07.2023 17:27, Tvrtko Ursulin wrote:
On 11/07/2023 14:58, Andrzej Hajda wrote:
On 11.07.2023 13:34, Andi Shyti wrote:
Hi Andrzej,
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11
+++
1 file changed, 11 insertions(+)
diff --git
a/drivers/gpu
From: Tvrtko Ursulin
With a few DRM drivers exposing per client memory stats via the fdinfo
interface already, we can add support for exposing the same data (albeit
aggregated for cgroup hierarchies) via the drm cgroup controller.
Add some driver callbacks and controller code to use them, walkin
From: Tvrtko Ursulin
To support container use cases where external orchestrators want to make
deployment and migration decisions based on GPU load and capacity, we can
expose the GPU load as seen by the controller in a new drm.active_us
field. This field contains a monotonic cumulative time cgrou
From: Tvrtko Ursulin
Simply refactor the existing helpers which collate the data for fdinfo
and share them with thin drm cgroup controller callbacks.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 4 +
drivers/gpu/drm/i915/i915_drm_client.c | 183 -
From: Tvrtko Ursulin
When notified by the drm core we are over our allotted time budget, i915
instance will check if any of the GPU engines it is reponsible for is
fully saturated. If it is, and the client in question is using that
engine, it will throttle it.
For now throttling is done simplist
From: Tvrtko Ursulin
Similar to CPU scheduling, implement a concept of weight in the drm cgroup
controller.
Uses the same range and default as the CPU controller - CGROUP_WEIGHT_MIN,
CGROUP_WEIGHT_DFL and CGROUP_WEIGHT_MAX.
Later each cgroup is assigned a time budget proportionaly based on the
From: Tvrtko Ursulin
Implement the drm_cgroup_ops->active_time_us callback.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 8 ++
drivers/gpu/drm/i915/i915_drm_client.c | 116 ++---
drivers/gpu/drm/i915/i915_drm_client.h | 2 +
3 files changed
From: Tvrtko Ursulin
To reduce the number of tracking going on, especially with drivers which
will not support any sort of control from the drm cgroup controller side,
lets express the funcionality as opt-in and use the presence of
drm_cgroup_ops as activation criteria.
Signed-off-by: Tvrtko Urs
From: Tvrtko Ursulin
Add a new callback via which the drm cgroup controller is notifying the
drm core that a certain process is above its allotted GPU time.
Signed-off-by: Tvrtko Ursulin
---
include/drm/drm_drv.h | 8
kernel/cgroup/drm.c | 16
2 files changed, 24 i
From: Tvrtko Ursulin
With the typical model where the display server opens the file descriptor
and then hands it over to the client(*), we were showing stale data in
debugfs.
Fix it by updating the drm_file->pid on ioctl access from a different
process.
The field is also made RCU protected to a
From: Tvrtko Ursulin
Add a driver callback and core helper which allow querying the time spent
on GPUs for processes belonging to a group.
Signed-off-by: Tvrtko Ursulin
---
include/drm/drm_drv.h | 28
kernel/cgroup/drm.c | 20
2 files changed
From: Tvrtko Ursulin
To enable propagation of settings from the cgroup DRM controller to DRM
and vice-versa, we need to start tracking to which cgroups DRM clients
belong.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_file.c | 6
include/drm/drm_file.h | 6
include/linu
From: Tvrtko Ursulin
To enable accounting of indirect client memory usage (such as page tables)
in the following patch, lets start recording the creator of each PPGTT.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11
From: Tvrtko Ursulin
Skeleton controller without any functionality.
Signed-off-by: Tvrtko Ursulin
---
include/linux/cgroup_drm.h| 9 ++
include/linux/cgroup_subsys.h | 4 +++
init/Kconfig | 7
kernel/cgroup/Makefile| 1 +
kernel/cgroup/drm.c
From: Tvrtko Ursulin
Account ring buffers and logical context space against the owning client
memory usage stats.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_context.c | 14 ++
drivers/gpu/drm/i915/i915_drm_client.c | 10 +++
From: Tvrtko Ursulin
Use the newly added drm_print_memory_stats helper to show memory
utilisation of our objects in drm/driver specific fdinfo output.
To collect the stats we walk the per memory regions object lists
and accumulate object size into the respective drm_memory_stats
categories.
Obj
From: Tvrtko Ursulin
Account page table backing store against the owning client memory usage
stats.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt
From: Tvrtko Ursulin
In order to show per client memory usage lets add some infrastructure
which enables tracking buffer objects owned by clients.
We add a per client list protected by a new per client lock and to support
delayed destruction (post client exit) we make tracked objects hold
refere
From: Tvrtko Ursulin
This series contains a proposal for a DRM cgroup controller which implements a
weight based hierarchical GPU usage budget based controller similar in concept
to some of the existing controllers and also exposes GPU memory usage as a read-
only field.
Motivation mostly comes
Uwe Kleine-König writes:
[dropping some recipients since my SMTP server was complaining about the size]
> Hello Thomas,
>
> On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote:
>> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
>> > Hello,
>> >
>> > while I debugged an issue in the
On 11.07.2023 22:31, Daniele Ceraolo Spurio wrote:
Due to a change in the auth flow on MTL, GuC 70.7.0 and newer will only
be able to authenticate HuC 8.5.1 and newer. The plan is to update the 2
binaries sinchronously in linux-firmware so that the fw repo always has
a matching pair that works; s
On 7/5/2023 10:44 AM, Suraj Kandpal wrote:
Calculations for YUV420 were missing from calculate_rc_param,
add them be in line with DSC 1.2a specs.
Signed-off-by: Suraj Kandpal
Suraj Kandpal (3):
drm/i915/dsc: Move rc param calculation for native_420
drm/i915/drm: Fix comment for YCbCr20
On 6/26/2023 7:26 PM, Luca Coelho wrote:
On Mon, 2023-06-26 at 18:35 +0530, Suraj Kandpal wrote:
Remove the FIXME and the code related to it as after verification
it does seem the previous values were typos and no hardware spec
mentions using these particular rc_params.
Signed-off-by: Suraj K
On 11/07/2023 23:02, Alan Previn wrote:
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 drive
On 12.07.2023 00:10, Nirmoy Das wrote:
On 7/11/2023 5:34 PM, Andrzej Hajda wrote:
Arrays passed to reg_in_range_table should end with empty record.
The patch solves KASAN detected bug with signature:
BUG: KASAN: global-out-of-bounds in
xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]
Read of
> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, July 12, 2023 1:44 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have
> differing sync polarities
>
> On Tue, 11 Jul 2023, Jani Nikula w
On Tue, 11 Jul 2023, Jani Nikula wrote:
> On Tue, 11 Jul 2023, Vidya Srinivas wrote:
>> v2: Add Jani Nikula's change for quirk for sync polarity
>
> This was a quick hack suggestion to try. If it works, I think it works
> by concidence, because a fastset won't update the sync flags in
> TRANS_DDI
57 matches
Mail list logo