Hi Jani and Joonas:
Are you OK with these patches? I noticed I need to change the license of the
new file. Will do that when check-in if you are OK with these.
Thanks,
Zhi.
On 3/28/22 6:50 AM, Christoph Hellwig wrote:
> On Fri, Mar 25, 2022 at 01:52:49PM -0400, Zhi Wang wrote:
>>
>> v7:
>>
>> -
On Thu, Mar 31, 2022 at 07:11:07AM +, Wang, Zhi A wrote:
> Hi Jani and Joonas:
>
> Are you OK with these patches? I noticed I need to change the license of the
> new file. Will do that when check-in if you are OK with these.
So I actually ended up testing the patches, and first they fail to
== Series Details ==
Series: series starting with [v7,1/3] i915/gvt: Separate the MMIO tracking
table from GVT-g (rev2)
URL : https://patchwork.freedesktop.org/series/101803/
State : failure
== Summary ==
Applying: i915/gvt: Separate the MMIO tracking table from GVT-g
Using index info to reco
Hi Chris:
Thanks for the testing. Can you attach the dmesg? I tested mostly on my skylake
desktop with some 3D workload.
Thanks,
Zhi.
On 3/31/22 7:42 AM, Christoph Hellwig wrote:
> On Thu, Mar 31, 2022 at 07:11:07AM +, Wang, Zhi A wrote:
>> Hi Jani and Joonas:
>>
>> Are you OK with these pa
On Thu, Mar 31, 2022 at 09:35:50AM +0200, Christian König wrote:
Well the fix is trivial, but somehow rebuilding drm-tip always fails
for me while merging drm-intel-next.
I probably have somehow messed up reverting the conflict resolution. Ideas?
It looks like the error is in the wrong confli
Drop extra ccflags, drop extra intermediate variables, list object files
one per line alphabetically.
Cc: Zhi Wang
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 4 +---
drivers/gpu/drm/i915/gvt/Makefile | 30 +++---
2 files changed, 24 insertions(+)
TRACE_INCLUDE_PATH should be a path relative to define_trace.h, not the
file including it. (See the comment in include/trace/define_trace.h.)
Cc: Zhi Wang
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gvt/trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
On Thu, 31 Mar 2022, "Wang, Zhi A" wrote:
> Hi Jani and Joonas:
>
> Are you OK with these patches? I noticed I need to change the license
> of the new file. Will do that when check-in if you are OK with these.
Use SPDX license header instead of the full text?
I don't know much about the actual c
The latest CI_DRM built is 11416; after that, there is build error:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c: In function
'amdgpu_gtt_mgr_recover':
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:200:31: error: 'struct
ttm_range_mgr_node' has no member named 'tbo'
amdgpu_ttm_recover_gart(node->
Adding a pile of people who've expressed interest in vm_bind for their
drivers.
Also note to the intel folks: This is largely written with me having my
subsystem co-maintainer hat on, i.e. what I think is the right thing to do
here for the subsystem at large. There is substantial rework involved
h
== Series Details ==
Series: series starting with [1/2] drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
URL : https://patchwork.freedesktop.org/series/102003/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4198a0bcbda7 drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
-:22: CHECK:SPACING: s
On Thu, Mar 31, 2022 at 10:20:58AM +0200, Christian König wrote:
Am 31.03.22 um 10:15 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 09:35:50AM +0200, Christian König wrote:
Well the fix is trivial, but somehow rebuilding drm-tip always
fails for me while merging drm-intel-next.
I probably
== Series Details ==
Series: series starting with [1/2] drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
URL : https://patchwork.freedesktop.org/series/102003/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separat
On Thu, Mar 31, 2022 at 08:04:04AM +, Wang, Zhi A wrote:
> Hi Chris:
>
> Thanks for the testing. Can you attach the dmesg? I tested mostly on my
> skylake desktop with some 3D workload.
Sure, I should have done that from the beginning:
[ 25.354587] vfio_mdev 6814f392-50ac-4236-ae3d-26d472
Thanks. Let me fix that. :)
On 3/31/22 04:33, Christoph Hellwig wrote:
On Thu, Mar 31, 2022 at 08:04:04AM +, Wang, Zhi A wrote:
Hi Chris:
Thanks for the testing. Can you attach the dmesg? I tested mostly on my skylake
desktop with some 3D workload.
Sure, I should have done that from the
== Series Details ==
Series: series starting with [1/2] drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
URL : https://patchwork.freedesktop.org/series/102003/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_dr
On Thu, Mar 31, 2022 at 08:28:09AM +, Tomi Sarvela wrote:
The latest CI_DRM built is 11416; after that, there is build error:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c: In function
'amdgpu_gtt_mgr_recover':
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:200:31: error: 'struct
ttm_range_mgr_n
Am 31.03.22 um 10:30 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 10:20:58AM +0200, Christian König wrote:
Am 31.03.22 um 10:15 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 09:35:50AM +0200, Christian König wrote:
Well the fix is trivial, but somehow rebuilding drm-tip always
fails for
On Wed, Mar 30, 2022 at 05:09:08PM -0700, Casey Bowman wrote:
Splitting i915_run_as_guest into a more arch-friendly function
as non-x86 builds do not support this functionality.
Signed-off-by: Casey Bowman
Reviewed-by: Lucas De Marchi
this is by no means and "RFC". For next patches please
After the latest CI_DRM has been build, re-test should be enough.
Tomi
> From: De Marchi, Lucas
> On Thu, Mar 31, 2022 at 08:28:09AM +, Tomi Sarvela wrote:
> >The latest CI_DRM built is 11416; after that, there is build error:
> >drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c: In function
> 'am
On Thu, Mar 31, 2022 at 10:39:47AM +0200, Christian König wrote:
Am 31.03.22 um 10:30 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 10:20:58AM +0200, Christian König wrote:
Am 31.03.22 um 10:15 schrieb Lucas De Marchi:
On Thu, Mar 31, 2022 at 09:35:50AM +0200, Christian König wrote:
Well th
== Series Details ==
Series: series starting with [1/2] drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
URL : https://patchwork.freedesktop.org/series/102003/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11416 -> Patchwork_22746
On 18/03/2022 18:12, Daniel Vetter wrote:
Maybe also good to add dri-devel to these discussions.
I'm not sure where exactly we landed with dgpu error capture (maybe I
should check the code but it's really w/e here), but I think we can
also toss in "you need a non-recoverable context for error ca
On Wed, 30 Mar 2022, Ville Syrjälä wrote:
> On Wed, Mar 30, 2022 at 08:04:26PM +0300, Jani Nikula wrote:
>> The invalid EDID block filtering uses the number of valid EDID
>> extensions instead of all EDID extensions for looping the extensions in
>> the copy. This is fine, by coincidence, if all th
This reverts commit 904ebf2ba89edaeba5c7c10540e43dba63541dc6.
Failures on dg2 tests were caused by invalid alignment when local memory
was in use. Changes which adopt alignment according to gen were already
merged in IGT so lets revert relocation temporary enabler for dg2. Keeping
it is a little b
== Series Details ==
Series: series starting with [1/2] drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
URL : https://patchwork.freedesktop.org/series/102003/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11416_full -> Patchwork_22746_full
==
From: Ville Syrjälä
(Hopefully) finish the static DRRS work:
- Finish off a bunch of fixed mode refactoring
- Allow fixed modes with any refresh rate, including ones
that exceed the panel's preferred mode. Useful for laptops
with high refresh rate panels (120-300Hz seen in the wild
so far)
From: Ville Syrjälä
Pull all the eDP specific platform/port checks out from
intel_drrs_init() into intel_edp_has_drrs().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 35 ++-
drivers/gpu/drm/i915/display/intel_drrs.c | 24
2 f
From: Ville Syrjälä
All the non-EDID fixed mode functions basically do the exact
same thing. Let's refactor the common bits into a shared
function.
There are minor differences on how the mode types are populated,
whether the display info physical size is updated, and the debug
print. The differe
From: Ville Syrjälä
Rather than having the connector init get the fixed mode back from
intel_panel and then feed it straight back into intel_panel_init()
let's just make the fixed mode lookup put the mode directly onto
the panel's fixed_modes list. Avoids the pointless round trip and
opens the do
From: Ville Syrjälä
intel_drrs_init() is a mostly pointless wrapper around
intel_panel_add_edid_downclock_mode(), get rid of it.
The only really useful thing left in there is the debug
print regarding the DRRS type supported by the connector.
Let's just move that into intel_panel_init().
Signed
From: Ville Syrjälä
Instead of duplicating the fixed/downclock modes we can just grab
the originals straight from the probed_modes list and keep them.
The next .get_modes() is going to repopulate the probed_modes list
anyway so whatever we leave there is just going to sit around until
that time w
From: Ville Syrjälä
We shouldn't restrict ourselves to just downclock modes with
lower refresh rate than the preferred mode. Laptops these
days can offer higher refresh rate modes as well.
Remove the arbitrary limit and allow all modes that, apart
from the clock, match the preferred mode.
Close
From: Ville Syrjälä
The intel_panel_add_edid_fixed_mode() vs.
intel_panel_add_edid_downclock_mode() split is not really
helpful. Let's just roll those into a single function so
that the connector init code doesn't have to care too much
about this. All we need to know is whether DRRS should be
all
From: Ville Syrjälä
Remove the "two fixed modes only" limit and grab as many
downclock modes from the EDID as we can find.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_panel.c | 42 +++---
1 file changed, 12 insertions(+), 30 deletions(-)
diff --git a/dr
From: Ville Syrjälä
Only seamless DRRS has specific hardware requirements so
we can allow static DRRS on any eDP port.
And we can replace these port checks and whatnot with
a simple check to make sure the transcoder(s) we're
about to use are capable of seamless DRRS.
Signed-off-by: Ville Syrjäl
From: Ville Syrjälä
Nothing special about static DRRS on LVDS, it's just your
bog standard modeset. Let's allow it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_lvds.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/inte
From: Ville Syrjälä
intel_drrs_compute_config() is 100% DP specific. DRRS on other
types of encoders wouldn't do any of these M2/N2 calculations
etc. So let's move this into intel_dp.c so all the DP state
calculation is more concentrated into one place.
Signed-off-by: Ville Syrjälä
---
drivers
One thing I've forgotten, since it's only hinted at here: If/when we
switch tlb flushing from the current dumb&synchronous implementation
we now have in i915 in upstream to one with batching using dma_fence,
then I think that should be something which is done with a small
helper library of shared c
On Tue, Mar 29, 2022 at 02:00:00AM +0300, Vinod Govindapillai wrote:
> Update DG2 init bw info similar to other platforms even though
> DG2 has constant bandwidh. This will avoid branching out DG2
> specific max bw calls.
>
> V3: Fix dg2_get_bw_info() and avoid handle special cases
> for DG2 (
== Series Details ==
Series: Revert "drm/i915/dg2: Add relocation exception" (rev3)
URL : https://patchwork.freedesktop.org/series/101669/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11431 -> Patchwork_22747
Summary
-
On Thu, 31 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rather than having the connector init get the fixed mode back from
> intel_panel and then feed it straight back into intel_panel_init()
> let's just make the fixed mode lookup put the mode directly onto
> the panel's fixed_modes
On Thu, 31 Mar 2022, Jani Nikula wrote:
> On Thu, 31 Mar 2022, Ville Syrjala wrote:
>> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
>> b/drivers/gpu/drm/i915/display/intel_drrs.c
>> index 1448c3029b8e..8fd280c7c83f 100644
>> --- a/drivers/gpu/drm/i915/display/intel_drrs.c
>> +++ b/driv
On Thu, Mar 31, 2022 at 04:04:57PM +0300, Jani Nikula wrote:
> On Thu, 31 Mar 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Rather than having the connector init get the fixed mode back from
> > intel_panel and then feed it straight back into intel_panel_init()
> > let's just make th
On 30/03/2022 20:52, Umesh Nerlige Ramappa wrote:
On Tue, Feb 22, 2022 at 01:55:55PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Tests and intel_gpu_top will share common code for parsing this file.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_fdinfo.c | 183
On 30/03/2022 21:11, Umesh Nerlige Ramappa wrote:
This looks very similar to existing perf_pmu tests with the slight
change that the busyness is now captured from the fdinfo.
Yep, much copy-and-paste was involved. :)
lgtm,
Reviewed-by: Umesh Nerlige Ramappa
Thanks!
Regards,
Tvrtko
Um
On Thu, 31 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> All the non-EDID fixed mode functions basically do the exact
> same thing. Let's refactor the common bits into a shared
> function.
>
> There are minor differences on how the mode types are populated,
> whether the display info p
On Thu, 31 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_drrs_init() is a mostly pointless wrapper around
> intel_panel_add_edid_downclock_mode(), get rid of it.
>
> The only really useful thing left in there is the debug
> print regarding the DRRS type supported by the connector
On Thu, 31 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The intel_panel_add_edid_fixed_mode() vs.
> intel_panel_add_edid_downclock_mode() split is not really
> helpful. Let's just roll those into a single function so
> that the connector init code doesn't have to care too much
> about
On Thu, 31 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of duplicating the fixed/downclock modes we can just grab
> the originals straight from the probed_modes list and keep them.
> The next .get_modes() is going to repopulate the probed_modes list
> anyway so whatever we lea
On Thu, 31 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the "two fixed modes only" limit and grab as many
> downclock modes from the EDID as we can find.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_panel.c | 42 +
On Thu, 31 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We shouldn't restrict ourselves to just downclock modes with
> lower refresh rate than the preferred mode. Laptops these
> days can offer higher refresh rate modes as well.
>
> Remove the arbitrary limit and allow all modes that,
On Thu, 31 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_drrs_compute_config() is 100% DP specific. DRRS on other
> types of encoders wouldn't do any of these M2/N2 calculations
> etc. So let's move this into intel_dp.c so all the DP state
> calculation is more concentrated into
On Thu, 31 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Only seamless DRRS has specific hardware requirements so
> we can allow static DRRS on any eDP port.
>
> And we can replace these port checks and whatnot with
> a simple check to make sure the transcoder(s) we're
> about to use a
On Thu, 31 Mar 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Nothing special about static DRRS on LVDS, it's just your
> bog standard modeset. Let's allow it.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_lvds.c | 3 ++-
> 1 file changed, 2 insertions(+), 1
From: Tvrtko Ursulin
This series contains four main components:
1. Per client support for intel_gpu_top.
2. IGT test for per client data exposed via fdinfo from i915.
3. Extracting intel_gpu_top code into shared IGT libraries - which makes
possible to write:
4. Vendor agnostic rudimentar
From: Tvrtko Ursulin
Tests and intel_gpu_top will share common code for parsing this file.
v2:
* Fix key-value parsing if valid key line ends with ':'.
* Add DRM_CLIENT_FDINFO_MAX_ENGINES. (Umesh)
* Always zero terminate read buffer. (Umesh)
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_fd
From: Tvrtko Ursulin
Use the i915 exported data in /proc//fdinfo to show GPU utilization
per DRM client.
Example of the output:
intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz
70% RC6; 0.62/ 7.08 W; 760 irqs/s
ENGINES BUSY
From: Tvrtko Ursulin
Mostly inherited from the perf_pmu, some basic tests, and some tests to
verify exported GPU busyness is as expected.
Signed-off-by: Tvrtko Ursulin
---
tests/i915/drm_fdinfo.c | 555
tests/meson.build | 8 +
2 files changed,
From: Tvrtko Ursulin
Code movement with some improvements to prepare for further work in
making a vendor agnostic gputop tool possible.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 386 +++
lib/igt_drm_clients.h | 102 +
lib/meson.build |
From: Tvrtko Ursulin
Prep code for incoming work.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_fdinfo.c | 2 ++
lib/igt_drm_fdinfo.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/lib/igt_drm_fdinfo.c b/lib/igt_drm_fdinfo.c
index d5c66881ed43..3926cbd25ecf 100644
--- a/lib/igt_drm_fdin
From: Tvrtko Ursulin
Instead of hard coding the engine names, allow a map of names to indices
to either be passed in or it gets auto-detected (less efficient) while
parsing.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 7 +++---
lib/igt_drm_clients.h | 3 ++-
lib/igt_drm_fdi
From: Tvrtko Ursulin
Intel_gpu_top gets it's main engine configuration data via PMU probe and
uses that for per client view as well. Furthemore code so far assumed only
clients belonging from a single DRM card would be tracked in a single
clients list.
Break this inter-dependency by moving the e
From: Tvrtko Ursulin
Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
to display a sorted by card and usage list of processes using GPUs.
Signed-off-by: Tvrtko Ursulin
Cc: Rob Clark
---
tools/gputop.c| 276 ++
tools/mes
From: Tvrtko Ursulin
Require DRM minor match during client lookup.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 14 --
lib/igt_drm_clients.h | 2 +-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index 1164
From: Tvrtko Ursulin
It is currently unused so no need to export it as API for now.
Also change the signature to take struct drm_client_fdinfo in order to
avoid needing to pass in a sized array.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 16
lib/igt_drm_clients
From: Tvrtko Ursulin
Prepare for supporting clients belonging to multiple DRM cards by storing
the DRM minor in the client record.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 33 -
lib/igt_drm_clients.h | 6 --
2 files changed, 24 insertions(+
From: Tvrtko Ursulin
Some libdrmclient operations require that inactive clients are last in the
list. Rather than relying on callers of the library sort routine to
implement their comparison callbacks correctly, enforce this order
directly in the library and let callers comparison callbacks conce
On Thu, Mar 31, 2022 at 04:59:11PM +0300, Jani Nikula wrote:
> On Thu, 31 Mar 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Nothing special about static DRRS on LVDS, it's just your
> > bog standard modeset. Let's allow it.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/g
From: Tvrtko Ursulin
Just a rebase - fully reviewed now.
Example of the intel_gpu_top output:
intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz
70% RC6; 0.62/ 7.08 W; 760 irqs/s
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram)
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamse
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multi
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not g
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver:
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
handed approach of adding a mid-layer to DRM.
i91
From: Tvrtko Ursulin
This will be useful to have at hand in a following patch.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 11 ++-
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 7 insertions(+
On 31/03/2022 01:09, Casey Bowman wrote:
Splitting i915_run_as_guest into a more arch-friendly function
as non-x86 builds do not support this functionality.
Signed-off-by: Casey Bowman
---
drivers/gpu/drm/i915/i915_utils.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gp
On 31/03/2022 00:48, Casey Bowman wrote:
Some functions defined in the intel-gtt module are used in several
areas, but is only supported on x86 platforms.
By separating these calls and their static underlying functions to
another area, we are able to compile out these functions for
non-x86 bui
== Series Details ==
Series: drm/i915: Finish off static DRRS (rev2)
URL : https://patchwork.freedesktop.org/series/101928/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11432 -> Patchwork_22748
Summary
---
**SUCCESS
On Tue, Mar 29, 2022 at 09:42:14PM +0300, Jani Nikula wrote:
> Add edid_block_check() that only checks the EDID block validity, without
> any actions. Turns out it's simple and crystal clear.
>
> Rewrite drm_edid_block_valid() around it, keeping all the functionality
> fairly closely the same, war
On Tue, Mar 29, 2022 at 09:42:15PM +0300, Jani Nikula wrote:
> Just i is a bit terse, clarify what it's about.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletion
On Tue, Mar 29, 2022 at 09:42:19PM +0300, Jani Nikula wrote:
> The code modifying the EDID block should not need to do tricks to fix
> the checksum. We have a function for computing the checksum, use it.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 2 +
== Series Details ==
Series: Revert "drm/i915/dg2: Add relocation exception" (rev3)
URL : https://patchwork.freedesktop.org/series/101669/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11431_full -> Patchwork_22747_full
Sum
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed. n
On Thu, 31 Mar 2022, Ville Syrjälä wrote:
> On Tue, Mar 29, 2022 at 09:42:14PM +0300, Jani Nikula wrote:
>> Add edid_block_check() that only checks the EDID block validity, without
>> any actions. Turns out it's simple and crystal clear.
>>
>> Rewrite drm_edid_block_valid() around it, keeping all
On Thu, 31 Mar 2022, Ville Syrjälä wrote:
>> -
>> -if (edid->revision > 4)
>> -DRM_DEBUG("EDID minor > 4, assuming backward
>> compatibility\n");
>
> This debug message seems to disappear. Intentional?
Intentional, but failed to mention it in the commit message.
On Thu, Mar 31, 2022 at 04:43:46PM +0300, Jani Nikula wrote:
> On Thu, 31 Mar 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We shouldn't restrict ourselves to just downclock modes with
> > lower refresh rate than the preferred mode. Laptops these
> > days can offer higher refresh rat
On Thu, Mar 31, 2022 at 07:49:10PM +0300, Jani Nikula wrote:
> On Thu, 31 Mar 2022, Ville Syrjälä wrote:
> >> -
> >> - if (edid->revision > 4)
> >> - DRM_DEBUG("EDID minor > 4, assuming backward
> >> compatibility\n");
> >
> > This debug message seems to disappear. Inten
On Tue, Mar 29, 2022 at 09:42:07PM +0300, Jani Nikula wrote:
> Another day, another batch of EDID code refactoring.
>
> Mostly the goal was to simplify drm_do_get_edid(), but trying to extract
> a const function for checking a single block validity lead me down a
> rabbit hole...
>
> BR,
> Jani.
On Wed, Mar 23, 2022 at 06:46:38PM +0100, Zbigniew Kempczyński wrote:
This reverts commit 904ebf2ba89edaeba5c7c10540e43dba63541dc6.
Failures on dg2 tests were caused by invalid alignment when local memory
was in use. Changes which adopt alignment according to gen were already
merged in IGT so le
On 31/03/2022 00:28, Matt Roper wrote:
Historically we've selected and programmed a single MCR group/instance
ID at driver startup that will steer register accesses for GSLICE/DSS
ranges to a non-terminated instance. Any reads of these register ranges
that don't need a specific unicast access
== Series Details ==
Series: drm/i915: Finish off static DRRS (rev2)
URL : https://patchwork.freedesktop.org/series/101928/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11432_full -> Patchwork_22748_full
Summary
---
This will make easy to extend MBUS joining support to future platforms
that also supports this feature.
Reviewed-by: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 6 +++---
2 files changed, 5 insertions(+), 3 del
v2 of https://patchwork.freedesktop.org/series/101931/
Rebased, review comments addressed.
BR,
Jani.
Jani Nikula (12):
drm/edid: use struct edid * in drm_do_get_edid()
drm/edid: clean up EDID block checksum functions
drm/edid: add edid_block_tag() helper to get the EDID extension tag
d
Mixing u8 * and struct edid * is confusing, switch to the latter.
v2:
- Rebase on the invalid block filtering fix
- Rename struct edid *base to *dest_block for clarity (Ville)
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 35 +--
It will be useful to accept a struct edid *, but for compatibility with
existing usage accept void *.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 8 +---
include/drm/drm_edid.h | 2 +-
2 files changed, 6 insertions(+), 4 dele
Have two clear functions, one to compute the checksum over the EDID, and
another to get the checksum from the EDID. Throw away the diff function.
Ditch the drm_ prefix for static functions, and accept const void * to
help transition to struct edid * usage.
Cc: Ville Syrjälä
Signed-off-by: Jani N
The extension tag at offset 0 is not present in struct edid, add a
helper for it to reduce the need to use u8 *.
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --g
1 - 100 of 150 matches
Mail list logo
